From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [rfc] Fix mst_solib_trampoline symbol sections for PLT stubs
Date: Wed, 31 Oct 2007 02:09:00 -0000 [thread overview]
Message-ID: <200710310136.l9V1adrr000915@d12av02.megacenter.de.ibm.com> (raw)
Hello,
we're still seeing problems on ppc when stepping over shared library
function calls, due to the issue previously discussed e.g. in:
http://sourceware.org/ml/gdb-patches/2006-06/msg00368.html
Now, at the time the discussion primarily focussed on ways how to
identify PLT stubs via e.g. code reading or BFD synthetic symbols.
However, looking at the existing code, it occurs to me that the
current method seems to be a valid approach, it's just that the
implementation is not quite correct.
The basic idea is to make use of a hint the linker adds to
undefined dynamic symbols. When the main executable imports
a function from a shared library, it will have an undefined
symbol refering to that function in its dynamic symbol table.
Now, for undefined symbols, the "value" is generally meaningless.
However, in this specific case, the linker actually may place a
significant piece of information into the value field: the address
of the PLT stub used to call the imported function.
It is my understanding that this information is generally reliable,
as it is implemented e.g. to determine the value of a function
pointer constant refering to that symbol (due to the special ABI
rule that the "address" of a function imported into the main
executable, for function pointer comparison purpuses, is the
address of the PLT stub in the main executable).
Thus, the current elf_symtab_read code attempts to use that hint
to construct a minimal symbol associating that address with the
name of the function. This is generally the correct thing to do,
as the code found at that address really is the stub used to call
that function.
However, this place in elf_symtab_read uses the section information
from the original undefined symbol as the section that synthetic
minimal symbol resides in . This seems not particularly useful to me,
as that section is of course always the "undefined" section.
This causes the minimal symbol to be defined in the "undefined"
section, which later on leads to it being ignored ...
Note that this is not a problem with minimal symbols in general,
nor even with mst_solib_trampoline symbols in general, only those
generated using this particular sort of hints in elf_symtab_read.
Thus my suggestion would be to fix this problem by creating those
symbols with a proper section in the first place. The patch I'm
proposing below attempts to do that by searching for the section
covering the VMA identified as PLT stub address. If it cannot
find any, the hint is ignored.
This patch fixes the ppc32 step-over-shared-library-call problem,
fixing about two dozen FAILs in the test suite.
Any comments on that approach? Am I missing something here?
Bye,
Ulrich
ChangeLog:
* elfread.c (elf_symtab_read): When constructing a solib trampoline
minimal symbol from an undefined dynamic symbol, use proper section.
diff -urNp gdb-orig/gdb/elfread.c gdb-head/gdb/elfread.c
--- gdb-orig/gdb/elfread.c 2007-10-21 01:24:25.000000000 +0200
+++ gdb-head/gdb/elfread.c 2007-10-21 14:39:09.702154927 +0200
@@ -240,6 +240,8 @@ elf_symtab_read (struct objfile *objfile
&& (sym->flags & BSF_FUNCTION))
{
struct minimal_symbol *msym;
+ bfd *abfd = objfile->obfd;
+ asection *sect;
/* Symbol is a reference to a function defined in
a shared library.
@@ -252,10 +254,28 @@ elf_symtab_read (struct objfile *objfile
symaddr = sym->value;
if (symaddr == 0)
continue;
- symaddr += offset;
+
+ /* sym->section is the undefined section. However, we want to
+ record the section where the PLT stub resides with the
+ minimal symbol. Search the section table for the one that
+ covers the stub's address. */
+ for (sect = abfd->sections; sect != NULL; sect = sect->next)
+ {
+ if ((bfd_get_section_flags (abfd, sect) & SEC_ALLOC) == 0)
+ continue;
+
+ if (symaddr >= bfd_get_section_vma (abfd, sect)
+ && symaddr < bfd_get_section_vma (abfd, sect)
+ + bfd_get_section_size (sect))
+ break;
+ }
+ if (!sect)
+ continue;
+
+ symaddr += ANOFFSET (objfile->section_offsets, sect->index);
+
msym = record_minimal_symbol
- ((char *) sym->name, symaddr,
- mst_solib_trampoline, sym->section, objfile);
+ ((char *) sym->name, symaddr, mst_solib_trampoline, sect, objfile);
if (msym != NULL)
msym->filename = filesymname;
continue;
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next reply other threads:[~2007-10-31 1:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 2:09 Ulrich Weigand [this message]
2007-10-31 3:17 ` Daniel Jacobowitz
2007-10-31 17:56 ` Ulrich Weigand
2007-10-31 18:06 ` Daniel Jacobowitz
2007-10-31 20:41 ` Ulrich Weigand
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=200710310136.l9V1adrr000915@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
/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