Can't debug x86_64 C++ programs.

[John Fine <johnsfine at verizon dot net>]

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.