From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [rfc] Fix ELF synthetic symbol size bug (affects PPC64)
Date: Mon, 05 Nov 2007 20:14:00 -0000 [thread overview]
Message-ID: <200711052014.lA5KEiTm019854@d12av02.megacenter.de.ibm.com> (raw)
Hello,
when debugging PPC64 test case problems, I noticed that symbol sizes
were completely broken. This turns out to be caused by elf_symtab_read
accessing the ELF-private part of the BFD symbols it processes in order
to find out the symbol size:
unsigned long size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
MSYMBOL_SIZE(msym) = size;
Now, this is not a problem when processing the regular or the dynamic
symbol tables, because the "asymbol" entries in those tables can in fact
be cast to elf_symbol_type. However, the same logic is used to process
the "synthetic" symbol table, and *those* are actually pure asymbol data
structures, and the above line will access some random memory.
The patch below fixes this by treating the synthetic symbol table
differently; this means that we do not get incorrect sizes, but it
unfortunately also means we do not get any sizes at all.
This is particularly problematic because on PPC64, the "regular"
symbol for a function points to the function descriptor, and the
actual code of the function is only identified by a synthetic
symbol. This means we basically do not get any size information
for functions at all.
Interestingly enough, BFD seems to actually have the size of the
function code available; it's just not possible right now to pass
that information through the "synthetic symbol" interface ...
Tested on powerpc64-linux, fixes about 20 FAILs.
I'd appreciate any comments, in particular whether I'm overlooking
a way to get at the sizes after all.
Bye,
Ulrich
ChangeLog:
* elfread.c (ST_REGULAR, ST_DYNAMIC, ST_SYNTHETIC): New defines.
(elf_symtab_read): Rename DYNAMIC argument to TYPE. Do not access
ELF-private symbol data when processing synthetic symbols.
(elf_symfile_read): Pass TYPE argument to elf_symtab_read.
diff -urNp gdb-orig/gdb/elfread.c gdb-head/gdb/elfread.c
--- gdb-orig/gdb/elfread.c 2007-11-01 14:50:26.000000000 +0100
+++ gdb-head/gdb/elfread.c 2007-11-05 20:04:50.915454504 +0100
@@ -180,14 +180,14 @@ record_minimal_symbol (char *name, CORE_
SYNOPSIS
- void elf_symtab_read (struct objfile *objfile, int dynamic,
+ void elf_symtab_read (struct objfile *objfile, int type,
long number_of_symbols, asymbol **symbol_table)
DESCRIPTION
Given an objfile, a symbol table, and a flag indicating whether the
- symbol table contains dynamic symbols, add all the global function
- and data symbols to the minimal symbol table.
+ symbol table contains regular, dynamic, or synthetic symbols, add all
+ the global function and data symbols to the minimal symbol table.
In stabs-in-ELF, as implemented by Sun, there are some local symbols
defined in the ELF symbol table, which can be used to locate
@@ -197,8 +197,12 @@ record_minimal_symbol (char *name, CORE_
*/
+#define ST_REGULAR 0
+#define ST_DYNAMIC 1
+#define ST_SYNTHETIC 2
+
static void
-elf_symtab_read (struct objfile *objfile, int dynamic,
+elf_symtab_read (struct objfile *objfile, int type,
long number_of_symbols, asymbol **symbol_table)
{
long storage_needed;
@@ -235,7 +239,7 @@ elf_symtab_read (struct objfile *objfile
continue;
offset = ANOFFSET (objfile->section_offsets, sym->section->index);
- if (dynamic
+ if (type == ST_DYNAMIC
&& sym->section == &bfd_und_section
&& (sym->flags & BSF_FUNCTION))
{
@@ -284,7 +288,7 @@ elf_symtab_read (struct objfile *objfile
/* If it is a nonstripped executable, do not enter dynamic
symbols, as the dynamic symbol table is usually a subset
of the main symbol table. */
- if (dynamic && !stripped)
+ if (type == ST_DYNAMIC && !stripped)
continue;
if (sym->flags & BSF_FILE)
{
@@ -324,8 +328,11 @@ elf_symtab_read (struct objfile *objfile
{
/* This is a hack to get the minimal symbol type
right for Irix 5, which has absolute addresses
- with special section indices for dynamic symbols. */
- unsigned short shndx =
+ with special section indices for dynamic symbols.
+
+ NOTE: uweigand-20071105: Synthetic symbols do not
+ have an ELF-private part, so do not touch those. */
+ unsigned short shndx = type == ST_SYNTHETIC ? 0 :
((elf_symbol_type *) sym)->internal_elf_sym.st_shndx;
switch (shndx)
@@ -484,9 +491,14 @@ elf_symtab_read (struct objfile *objfile
msym = record_minimal_symbol
((char *) sym->name, symaddr,
ms_type, sym->section, objfile);
- if (msym)
+
+ /* Pass symbol size field in via BFD. FIXME!!!
+
+ FIXME: uweigand-20071105: This unfortunately does not work
+ for synthetic symbols, as they do not have an ELF-private part.
+ This means we will not get sizes for ppc64 functions. */
+ if (msym && type != ST_SYNTHETIC)
{
- /* Pass symbol size field in via BFD. FIXME!!! */
unsigned long size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
MSYMBOL_SIZE(msym) = size;
}
@@ -569,7 +581,7 @@ elf_symfile_read (struct objfile *objfil
error (_("Can't read symbols from %s: %s"), bfd_get_filename (objfile->obfd),
bfd_errmsg (bfd_get_error ()));
- elf_symtab_read (objfile, 0, symcount, symbol_table);
+ elf_symtab_read (objfile, ST_REGULAR, symcount, symbol_table);
}
/* Add the dynamic symbols. */
@@ -587,7 +599,7 @@ elf_symfile_read (struct objfile *objfil
error (_("Can't read symbols from %s: %s"), bfd_get_filename (objfile->obfd),
bfd_errmsg (bfd_get_error ()));
- elf_symtab_read (objfile, 1, dynsymcount, dyn_symbol_table);
+ elf_symtab_read (objfile, ST_DYNAMIC, dynsymcount, dyn_symbol_table);
}
/* Add synthetic symbols - for instance, names for any PLT entries. */
@@ -605,7 +617,7 @@ elf_symfile_read (struct objfile *objfil
for (i = 0; i < synthcount; i++)
synth_symbol_table[i] = synthsyms + i;
make_cleanup (xfree, synth_symbol_table);
- elf_symtab_read (objfile, 0, synthcount, synth_symbol_table);
+ elf_symtab_read (objfile, ST_SYNTHETIC, synthcount, synth_symbol_table);
}
/* Install any minimal symbols that have been collected as the current
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next reply other threads:[~2007-11-05 20:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-05 20:14 Ulrich Weigand [this message]
2007-11-05 20:22 ` Daniel Jacobowitz
2007-11-06 21:33 ` [rfc, v2] " Ulrich Weigand
2007-11-06 21:44 ` Daniel Jacobowitz
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=200711052014.lA5KEiTm019854@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