This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
Can't debug x86_64 C++ programs.
- From: John Fine <johnsfine at verizon dot net>
- To: insight at sourceware dot org
- Date: Tue, 16 Sep 2008 17:27:45 -0400
- Subject: Can't debug x86_64 C++ programs.
Actually X86_64 C++ programs are the only things I've even tried to
debug with Insight. So I don't have any good guess of what I might be
trying that differs from what those who can use Insight are doing.
When I try to use it, Insight has so many bugs, I couldn't begin to list
them here and other bugs interfere with any attempt to understand or
work around any specific bug.
If there is any chance of getting any support, I'd be glad to do
specific tests or give much more detail of the failures.
I really need a GUI debugger for x86_64 C++ programs. I've tried kdbg,
which has many of the same bugs (which implies they are in gdb it self,
not in the GUI), but some of those don't happen when I try gdb alone.
Also kdbg seems to be missing features needed for practical debugging,
features Insight has, if only it worked. If you know of a GUI debugger
that works, please tell me.
Some of the bugs:
The step over buttons (both "Next" and "Next Asm") usually do a step
into. They sometimes step over, so they must be connected to the right
thing, but usually they step into.
The Finish button usually does nothing, sometimes does the step out of
operation that I want and sometimes causes the program being debugged to
seg fault. If I restart the program and set a breakpoint where a
correct step out of would reach and get into the same place as before
and just continue, the breakpoint will be hit, but even with the
breakpoint there a Finish will make the program seg fault.
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.
I normally want to work in SRC+ASM mode. The compiler has often put asm
instructions in a strange order relative to source lines and I'm used to
that and (in Windows debuggers) know how to work around it with the dual
view. Insight keeps changing its mind about which view is on top (opens
with source on top, then changes back and forth for reasons I can't
begin to guess). That is very distracting.
If I set a breakpoint on a source line, it shows on an asm line that is
probably a plausible choice given the debug info the compiler generated
(but often isn't a usable choice for actual debugging). If I set a
breakpoint on an asm line, it only sometimes gets marked on the correct
source line. But I've used objdump to verify that the debug info
generated by the compiler is correct enough that the asm line in
question can be traced to the correct source line. When it goes to a
wrong source line, I'm pretty sure that wrong line is in a totally wrong
file, not just the wrong line of the current file.
If it hits a breakpoint set in the asm view, even if it originally did
mark that correctly in the source view, it almost never opens the right
source view. It seems to pick an hpp from which the compiler inlined
code elsewhere in the same function. I used objdump to see if the debug
info was wrong, and it wasn't. Anyway, the dual view then shows the
correct asm code and incorrect source code. If I step, the source code
stays in the same wrong file, but I think it uses the source line number
that would be correct if it were in the right source file.
I expect someone will tell me I should have completely unoptimized code
when debugging. That usually isn't practical. I know how to deal with
all the strange sequence and inlining effects using dual view in a
working GUI debugger. The failures I've described above happen even in
functions where the optimization did nothing strange.