This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
Re: Can't debug x86_64 C++ programs.
- From: John Fine <johnsfine at verizon dot net>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: insight at sourceware dot org
- Date: Wed, 17 Sep 2008 08:46:02 -0400
- Subject: Re: Can't debug x86_64 C++ programs.
- References: <48D024D1.3000107@verizon.net> <48D0A482.8060000@redhat.com>
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.