From: Keith Seitz <keiths@redhat.com>
To: John Fine <johnsfine@verizon.net>
Cc: insight@sourceware.org
Subject: Re: Can't debug x86_64 C++ programs.
Date: Thu, 18 Sep 2008 21:19:00 -0000 [thread overview]
Message-ID: <48D0A482.8060000@redhat.com> (raw)
In-Reply-To: <48D024D1.3000107@verizon.net>
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
next prev parent reply other threads:[~2008-09-17 6:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 20:53 John Fine
2008-09-18 21:19 ` Keith Seitz [this message]
2008-09-18 21:37 ` John Fine
2008-09-19 7:26 ` Keith Seitz
2008-09-19 14:27 ` John Fine
2008-09-19 18:47 ` Keith Seitz
2008-09-18 22:11 ` John Fine
2008-09-18 22:27 ` John Fine
2008-09-18 23:04 ` Keith Seitz
2008-09-18 23:25 ` John Fine
2008-09-19 8:20 ` Keith Seitz
2008-09-19 13:27 ` John Fine
2008-09-19 16:38 ` Keith Seitz
2008-09-20 21:22 ` John Fine
2008-09-22 18:35 ` John Fine
2008-09-19 2:17 ` Keith Seitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D0A482.8060000@redhat.com \
--to=keiths@redhat.com \
--cc=insight@sourceware.org \
--cc=johnsfine@verizon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).