From: John Fine <johnsfine@verizon.net>
To: Keith Seitz <keiths@redhat.com>
Cc: insight@sourceware.org
Subject: Re: Can't debug x86_64 C++ programs.
Date: Fri, 19 Sep 2008 14:27:00 -0000 [thread overview]
Message-ID: <48D2D57F.6070004@verizon.net> (raw)
In-Reply-To: <48D2C56C.2020105@redhat.com>
Keith Seitz wrote:
> The good news is that it is now my job to make gdb a better c++
> debugger, so my knowledge grows every day.
Can I put in an early request (maybe you've heard this one already) to
do something about the absurdly long function names.
In viewing disassembly, you get function name + offset as one of the
items on the line, but in typical templated code the function name is so
long that the actual disassembly is pushed off the right edge of the
display.
I can't think of a decent method to make a more concise display of
function name (maybe you can). But failing that, I think you need an
option to drop it entirely. Or is there such an option already that I
just haven't found? I'm not very good at using gdb. function name +
offset was never such valuable information that we really needed it and
when it is too bulky to use, it should go away.
For Insight's SRC+ASM view, I think putting the source line number on
each line in both panels would help a lot (again if that option is
already there, I'm not expert). While that is less critical for gdb
itself than for a GUI, I think it would be a very useful option in gdb
itself (disassemble with the source line number shown on each line of
disassembly). Hopefully other GUI's layered on gdb would give the user
access to that feature.
If you're not totally turning off optimization, any user looking at a
disassembly spends a lot of time figuring out which source line is
connected to each asm line. It would make more sense for the debugger
to just display the compiler's version of that information.
next prev parent reply other threads:[~2008-09-18 22:27 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
2008-09-18 21:37 ` John Fine
2008-09-19 7:26 ` Keith Seitz
2008-09-19 14:27 ` John Fine [this message]
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=48D2D57F.6070004@verizon.net \
--to=johnsfine@verizon.net \
--cc=insight@sourceware.org \
--cc=keiths@redhat.com \
/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).