On Wed, Aug 25, 2004 at 11:36:37AM -0400, Elliot Lee wrote: > On Tue, 24 Aug 2004, Guolin Cheng wrote: > > > Nowadays it is not rare that we Linux FC1 users have to use binary-only > > modules or user-space binaries, and even worse, those binaries are > > reporting problems from time to time. > > > > Are there any tools can we use to debug these binary-only user-space > > programs and kernel-space modules at first hand? > > There's no point in debugging something unless you have the sources to fix > the problem, or you're in touch with someone who has the sources... > > FWIW, gdb *can* debug binary-only apps. It just won't print out the source > code for you during the debugging session. :-) Perhaps if you told us something more about what you intend to debug. If you only have a binary to debug then you have to think about this as an exercise at the assembly language level. Some simple logic errors can be fixed by a binary patch. i.e. for off by one constant errors you might be able to change the constant. Logic equal versus greater than or equal... etc. It is possible to disassemble a program and modify the assembler and 'recompile'. If you run your binary under strace you can see the system calls it makes and see if they make sense. With modern languages and optimizations like C++ it is difficult to make sense of the generated assembler code. A common stripped binary will have enough symbols so the runtime link loader can link it to standard libraries. If your program is making an error in a library function you can look at hacking a fix in that library function. The only way to learn how do this is to start with small simple C programs and functions with errors you understand and then debug those with and without symbols, and then with and without optimizations. Bottom line -- without source, how do you intend to fix the problem once you have figured it out. -- T o m M i t c h e l l Just say no to 74LS73 in 2004
