Re: Can't debug x86_64 C++ programs.

[John Fine <johnsfine@verizon.net>]

Keith Seitz wrote:
> Unfortunately, insight is quickly approaching EOL. I have been about 
> the only person to keep it hobbling along for quite some years, and I 
> am just about ready to spend my copious free time on some other project.
Can you give me some hints where in the GDB/Insight source code certain 
operations are done?  I think I might be able to fix or at least 
understand some of these bugs myself.

I'd especially like to have the nexti button actually work (rather than 
usually step in).  I can't imagine how that bug could be the GUI's 
fault.  It only makes sense if the GDB code for nexti can't recognize a 
call instruction in x86_64 asm code.  I'd really like to look at the 
code in gdb that tries to determine whether the next instruction is a 
call.  (Maybe it is confused by the possible encodings of call or maybe 
it is confused by the 64-bit virtual address and sometimes looking in 
the wrong place.)  But I don't know how to find that code.

> Isolated test cases are very useful.
I'll see what I can find time to create.  So far I haven't tried to 
debug anything small, so I don't know whether Insight would behave 
differently.  I haven't found any target programs in which insight 
doesn't have these malfunctions.  There are calls in each program for 
which gdb/Insight can correctly step over or out.  There are lines in 
the source code of each for which gdb/Insight seems to understand the 
correspondence between source and asm.  But in every program, there are 
lines where it doesn't.

A lot of the debugging I attempted, and some of the worst gdb/Insight 
behavior I saw) was with the program opannotate that is part of oprofile 
package.
It is Oprofile version 0.9.3 (because the build for the newer Oprofile 
was unhappy with some older libraries on our Centos system).  It was 
built with gcc version 3.4.6 with switches -g O2.
I tried Insight versions 6.7.1 and 6.8.  In 6.7.1 I made the obvious 
changes to the several casts that caused the build to fail.

In Opannotate, I just wanted to understand some of the basic flow of the 
program that I couldn't figure out from the source code.  So I just 
wanted to do a bunch of step over and a few step into operations.  But I 
spent all my time trying to get out of the functions that I stepped into 
using the step over button and never reached the parts I wanted to see.

Most of what I'm attempting to debug is in a large closed source project 
compiled with the Intel 10.0 compiler.  I tried using GCC 3.4.6 for the 
parts of that which I wanted to debug, but that just made debugging 
harder.  Neither Intel nor GCC is great about correctly identifying the 
source line for each asm line.  But GCC is by far the worse of the two 
at that.  Most of the errors in the correspondence between source and 
asm are made in the debugger (I'm trusting Objdump as the arbiter) but 
starting with lots of errors in that made by the compiler still makes 
things worse.

Another place I'd really like some hints about gdb/Insight source code 
location is in the construction of the text that goes into the asm 
window.  I probably won't understand the code well enough to make the 
change I'd like, but I want to look and see if I can.  On each line of 
asm code, I'd like display the line number of the source line that the 
debugger thinks the debug info tells it corresponds.  If I really 
understood how to change things, I'd also color code that, to flag the 
places where the source filename is different.  If practical, I would 
also drop the display of the function+offset version of the address.  In 
C++ code function names get too messy and the plain virtual address 
should be good enough.
>
>> If I try to view the registers window anytime after pressing Run, the 
>> whole debugger crashes.  If I view the register window first, it 
>> appears, then when I press run it populates, then a moment later the 
>> whole debugger crashes.
>
> Once again, I am sorry, but I cannot reproduce this (on x86).
I haven't checked yet whether I can get a core file.  If I can, then I 
can reload that in gdb and get a backtrace.
>
> Holy moly! Do they really do that? I admit that I seldom use SRC+ASM, 
> but the way that code is arranged in insight, I would have thought 
> that it was impossible for the SRC and ASM panes to swap back and 
> forth. I would definitely like to see a test case for this.
I'm not certain, but I think it happens when the debugger thinks the 
source file has changed.  I do a step across an asm instruction and 
(because of inlining) the source file might change.  The compiler's 
rules (especially GCC) for identifying the line number in cases of 
inlining seem to be seriously bogus.  The debug info often stays at the 
highest level (so the source file wouldn't change) but sometimes digs in 
a layer or two.  By any reasonable definition, the source file 
identified by the debug info differs from reality and the understanding 
by the debugger differs again from that debug info.  But at some points 
the debugger understands the source file has changed on a step of an 
ordinary instruction within a function.  Then the contents of the source 
pane change to the other position and if the source pane was on top, it 
moves to the bottom.  I'm not sure that case can also move the source 
pane back to the top, but something can, because it doesn't stay on the 
bottom.

If it shouldn't swap, where should it stay (top or bottom)?
> Insight does not do anything with breakpoints other than display them. 
> This is almost certainly a gdb problem. Nonetheless, given that I've 
> been working on gdb and C++, I would appreciate it if you could send 
> me a test case for this so that I can integrate it into the test suite.
When you set a breakpoint in asm view, Insight sometimes displays the 
red mark in both asm view and source view.  Is it really gdb code that 
tells it where to display the red mark in source view?

I hope I wasn't unclear about that pair of bugs.  When I set a 
breakpoint in asm view gdb/Insight seem to be rock solid about setting 
the breakpoint on the correct asm instruction and when you press 
continue actually stopping on the correct asm instruction.  The problems 
are that it usually doesn't (but sometimes does) mark a line in the 
source view when you set the breakpoint (even though the Objdump output 
from the same code identifies a source line for that asm line that is 
within view).  The other problem is when it hits the breakpoint, it 
displays the wrong file in the source pane.