My own experience has been in debugging heavily templated C++ code, often in optimized builds with debug info (rather than unoptimized debug builds). GDB seems to use and trust the debug info in cases where it is fundamentally not trustworthy. Source level debugging may require using and trusting the debug info. In Visual Studio I switch to assembly level debugging specifically when and because I know the debugging info is unsound. In Visual Studio, assembly level debugging is practical even when debugging info is wrong. In my experience, in GDB that is not the case. If you try to step into or over a call in the disassembled code, GDB will use the debug info, rather than the disassembled code to perform that action. It will get totally lost of the debug info regarding that call instruction was wrong and your whole debugging session is trashed. So I guess you have given the right answer for the trivial case where you might want but not need assembly level debugging. If you really need it, it is not so easy. On 07/10/15, Andrew Haley wrote: On 07/10/2015 06:03 PM, xparmenides wrote: > 1. To debug at assembly level, the steps to compile is so complicated > that is somewhat impractical. Is there any way make the process easily? Yes. Compile your program C in the normal way, then: b main r disp/i $pc si si si ... etc. Andrew.
