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

[Keith Seitz <keiths at redhat dot com>]

John Fine wrote:
> 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.

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.

As you've discovered, there are a ton of problems. Unfortunately, it 
takes an experienced eye to recognize the difference between a problem 
with the GUI and gdb. Gdb is pretty much the worst debugger on the 
planet when it comes to C++. Sad but true.

Red Hat and other companies (and interested parties) are attempting to 
make gdb a better C++ debugger. You might want to keep an eye on the 
archer project at sourceware.org. It's probably quite a while out, 
though, before anything substantially useable is ready.

> 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.

Isolated test cases are very useful. I don't often use x86_64, but I do 
now have access to such a box. For right now, all my comments below 
apply to running insight on x86. I will try to verify all of your issues 
on x86_64 by the end of the week.

> If you know of a GUI debugger that works, please tell me.

You might try the CDT project in Eclipse or even some of the debuggers 
mentioned off of the insight homepage hosted on sourceware.org. I have 
no experience with those unfortunately, and they are all based on gdb, 
so it is unlikely that C++ debugging is going to be any better than what 
you are experiencing now.

> 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.

That is very odd. I certainly have never experienced this, and I have 
actually been using insight almost daily now for several weeks. Can you 
give me a test case? By the way, what version of insight are you 
attempting to use? [insight -v or "show version" in a console window] 
What compiler?

> 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.

I am sorry, but I also have not encountered these problems, and believe 
me when I say I've been using "finish" a awful lot of late, debugging 
gdb's symbol code with C++. Can you provide me with a test case?

> 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 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.

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.

> 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.

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.

> 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.

It is not possible for me to say whether anything is misbehaving. If you 
are correct, it certainly sounds like there is a problem with 
gdb/insight. Optimization is a strange beast, but it sounds like you 
already are well-aware of the pitfalls of debugging optimized code.

Once again, I must apologize and ask for a test case. I simply have not 
seen the issues you are reporting _on x86_. I will attempt to 
double-check your findings against x86_64 this week, but if you have 
test cases for any of these, it would certainly make things a whole lot 
easier.

Keith