[root#xxx~]# which strace
/usr/bin/strace
I want to debug how it actually works,but can't find its debug symbols,where is it?
Programs shipped in Linux distributions do not usually have debug symbols in the executables (they are sometimes in a separate file that can be downloaded). You can get the source code here, though, and compile it with debug symbols.
Related
I have java application which is calling c/cpp code (it is .so files) using JNI.
I am using API's from this .so files. I have to debug .so files, how to debug it?
I tried below things:
I attached gdb to xyz.so and add breakpoints.
run java code
but not able to hit breakpoint.
can you suggest how to debug it.
after breakpoint, I can not run r or c (continue).
so how can we debug in such case?
thanks in advance.
When you compile something, as output, you have assembly code (which is run by the computer) and the symbols (which are the association between your source code and the assembly code).
In order to debug the C/C++ part, you must have the appropriate symbols in order to be able to place a break point with the same user experience you have in java. Otherwise, you'll just see a huge sequence of numbers and what you are doing is actually reverse engineering the code.
Therefore, you need the symbols which are not shipped by default (you should ask the vendor if they can provide them).
Stack: MIPS, Linux, C, C++ using GNU Tools to compile and link (building on x86 for MIPS)
Fair warning: I'm a C, C++ novice, feel free to suggest anything which might be obvious as it's possible I have not tried it yet.
I am able to build an executable which dynamically links to a library (live555), if I statically link to this everything works fine, however when I attempt to dynamically link the executable crashes during runtime. To confirm I am building the .so files correctly, I've also tried building other executables (the test tools included with live555) to dynamically link against these .so libs and these tools work fine.
The linking/build seems to work fine, no errors or warnings are thrown during the build. I can inspect the crashing executable with readelf -d and clearly see the .so references. I can also run ldd on the MIPS system on the executable and the libraries seem to be loaded fine, strace output also shows these libraries as being loaded. Unfortunately the strace output doesn't really provide me with any insite, I've talked with others familiar with this system and they are not sure what the problem is.
Just looking for ideas and tools to try, if anyone has any thoughts I'd appropriate them!
Thanks for reading
There is not enough information here to start troubleshooting in depth. Some ideas to start debugging, from least to most time-consuming:
After you run ldd on your executable, check the path(s) where that library is being loaded from, make sure the library is the version you compiled / linked against. Easy way is to get it's MD5 hash on your target and host, make sure they are the same.
Also check to make sure you don't have multiple instances of the library installed
Double check the aliases for your library, make sure they point to the same place
Try enabling crash dump generation $> ulimit -c unlimited, run gdb or DDD, load the crash dump and inspect your environment.
Check your CFLAGS, it could be as #YannRamin said, you need -fPIC for MIPS. You can run make -n to see how your binary is being generated.
Check your LDPATH env on target and make sure it is sensible; empty is perfectly fine btw.
Check your LDFLAGS during compile / linking. You might have to run make -n, look for gcc command or collect command, then copy-paste the entire line and add --verbose to the end so you can see exactly what the linker is doing. You might have to fix paths for sources / object files, depending on how your build system is setup.
The idea is to try and eliminate potential issues, such as:
wrong library version: installed vs compiled against
multiple locations / bad aliasing
symbol pollution when compiling / linking
many others
You're lucky that you have Linux installed, so should be fairly easy, just might be time consuming.
Last week I released the Linux and windows version of an application.
And after the release we realized that the symbols were not stripped off, and my manager thinks (and I disagree) that it might allow the user to understand our algorithm.
Anyway, now, I will have to clean-up the symbols and re-release the application.
My question,
What is the best way to strip symbols in Linux?
What is the best way to strip symbols in Windows?
With Visual C++ (and other Microsoft compilers) on Windows, symbols aren't part of the binaries. Instead, they are stored in separate files called "Program Database" files (.pdb files). Just don't provide the .pdb files.
With the GNU toolchain you would use strip to remove symbols from the binaries.
For the GNU toolchain, there exists a cool sleight of hand:
objcopy --only-keep-debug yourprogram ../somepath/yourprogram.dbg
strip yourprogram
objcopy --add-gnu-debuglink=../somepath/yourprogram.dbg yourprogram
Now you can zip the folder your program is in (or pack it into an installer or whatever), there will be no more debug symbols in it.
BUT : If you launch the debugger or if you run a tool like addr2line or obdump, the tool will (thanks to the debuglink info) automagically know where to find the symbols and load them.
Which is awesome, because it means you have the benefits of having symbols on your end, without distributing them to the user.
I was digging around and found an executable for something I wrote in Visual C++ 6.0 about 8 years ago. I never backed up the source code, but I think I always compiled everything in debug mode. I also vaguely remember hearing somewhere that "you can't decompile an executable into source code unless you have your compiler's debugging symbols or something." The code would have sentimental value, but its not mission-critical that I retrieve it.
That's the background; here are the questions:
How do I check if an executable was compiled in debug mode or not?
If it is, what information comes with a debug mode executable?
Can I retrieve full source code? Failing that, can I get any substantial improvement when decompiling compared to a release version? If so, how?
Thanks,
-- Michael Burge
I do not believe there is a flag though you might find something by using PEDUMP which will dump out COFF file formats (Windows EXE and DLLs). You can infer if an executable was compiled for debug rather quickly by running Dependecy Walker and seeing if your EXE is linking to any debug DLLs (suffixed with D, e.g. MSVCRT5D.DLL).
FYI in VC6 Debug and Release are simple named builds, not modes per say, each build a collection of compiler and linker settings. The EXE is just code, debug exes normally not having been optimized which makes using a debugger with it easy (versus debugging optimized code). Thus you can compile a Release binary with Debug Symbols which is sometimes useful for tracking down optimized code errors.
Debug EXEs and DLLs did not contain any debugging information but instead had a sidecar PDB file that resided in the same folder and contains all the debugging symbols information that was produced during compilation.
No, source is source and not compiled into the symbols file or executables. There are some amazing decompilers out there that can regenerate decent C versions of your code but they are amazing only in how good the C is, not in how well they can recreate your source.
With Visual Studio, I am afraid you can't, since the debug executable doesn't contain the source. Visual Studio generates pdb files that only contains the mapping between the binary and the sources filenames and line numbers, but you still need the source code with them. That might be different with gcc, which I think integrate the source itself inside the binaries.
I think that many disassemblers can show the source if a binary is compiled in debug mode. For example, I use OllyDBG and it has an option to show the source, although I've never tried.
i'm using gdb 7.2 on ubuntu 10.10
while stepping with step i get to a point that looks (literally) like this:
0x00130a2c in boost::contexts::context::impl_t::impl_t(void (*)(void*), void*, unsigned int, boost::contexts::context::impl_t*, std::auto_ptr<boost::contexts::context::allocator_base>) () from /home/lurscher/third_party/boost_1_45_0/stage/lib/libboost_context.so.1.45.0
So i want now to associate the appropiate source files; which likely should be on /home/lurscher/third_party/boost_1_45_0/boost/context and /home/lurscher/third_party/boost_1_45_0/libs/context.
But the truth is i'm not sure how to achieve this, its been years since i had to debug in terminal mode
You can compile the third-party library with debugging symbols, and those debugging symbols will chain [i.e. if your app is compiled with debugging symbols, you can step through and see the source lines even within the library]
boost jam takes a debug argument which will instruct it to build a debug version.
in gcc, debug symbols is -g
If your library is compiled in the debug mode, but GDB just doesn't find the sources, you should use the dir command to add the source directory to the search list.