From: Arnab Bhaduri <arnab@cadence.com>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Cc: Tom Tromey <tromey@redhat.com>
Subject: RE: gdb not detecting function sections correctly for functions in overlays
Date: Mon, 14 Oct 2013 16:29:00 -0000 [thread overview]
Message-ID: <D3CD0638AD056342925227F12D6A2AB50913E2E289@MAILSJ3.global.cadence.com> (raw)
In-Reply-To: <8761t580mi.fsf@fleche.redhat.com>
Thanks for your reply. Yes, I came to the same conclusion after digging around in the DWARF information. I had not been familiar with DWARF, or else I might have reached that conclusion much sooner.
I have made a couple of local changes that make things work better for me. Perhaps you could give me your opinion on these (described below).
1) add_location_to_breakpoint() (breakpoint.c) - this calls set_breakpoint_location_function() which sets the function name incorrectly because it uses the PC-to-section lookup. I modified this like so: if the "symtab_and_line * sal" argument's section is an overlay section, and sal->symtab is not null, then walk over all the symbols in the symtab and find the one with a line number that is closest to (but not larger than) the line number specified in the sal. With this best match symbol, search all the overlay sections for a name match. If there is a match, select that overlay section and update the bp_location. Of course this will not work if e.g. I define two functions with the same name in two different overlays. In that case I warn the user and arbitrarily choose the first one found.
2) find_function_start_sal() (symtab.c) - this calls find_pc_sect_line() to look up the section, and fails when the PC-to-section lookup fails for overlays. It was not clear to me why it does not use the symtab in the symbol itself, which is passed in as an argument. I made a change here to use the symbol's symtab if it has one.
Arnab
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Subject: Re: gdb not detecting function sections correctly for functions
> in overlays
>
> objdump --syms will show the ELF symbols, but not the DWARF symbols.
> But if you have debuginfo, gdb will generally prefer the DWARF.
> This may explain the discrepancy there.
>
> Maybe this is a regression from my patch series to change how symbol
> sections are represented. That would be my guess, anyway, if earlier
> versions of gdb worked.
>
> Anyway, there is no high road to fixing this -- just debugging gdb.
>
> I don't think there's a good way of associating a DWARF symbol with a
> particular overlay. That seems to be the root of the problem to me.
>
> Tom
next prev parent reply other threads:[~2013-10-14 16:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 20:02 Arnab Bhaduri
2013-10-10 18:03 ` Tom Tromey
2013-10-14 16:29 ` Arnab Bhaduri [this message]
2013-10-22 16:53 ` Tom Tromey
2013-10-22 17:32 ` Pedro Alves
2013-10-22 17:38 ` Arnab Bhaduri
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=D3CD0638AD056342925227F12D6A2AB50913E2E289@MAILSJ3.global.cadence.com \
--to=arnab@cadence.com \
--cc=gdb@sourceware.org \
--cc=tromey@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