This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] When can we remove Sun-specific stabs support? (when will it be ok to delete partial_symtab.section_offsets?)
- From: Doug Evans <dje at google dot com>
- To: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 7 May 2015 15:52:30 -0700
- Subject: Re: [RFC] When can we remove Sun-specific stabs support? (when will it be ok to delete partial_symtab.section_offsets?)
- Authentication-results: sourceware.org; auth=none
- References: <90e6ba6e87129285600515847ec6 at google dot com>
On Thu, May 7, 2015 at 2:21 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> While working on improving some symbol table code I stumbled on
> partial_symtab.section_offsets and that led me to elfstab_offset_sections.
>
> AFAICT, the only reason partial_symtab.section_offsets exists is for
> Sun stabs. There are no regressions if I comment out
> elfstab_offset_sections on linux+stabs.
> Grep for Ddata.data in doc/stabs.texinfo for further background.
>
> elfread.c:
>
> /* When handling an ELF file that contains Sun STABS debug info,
> some of the debug info is relative to the particular chunk of the
> section that was generated in its individual .o file. E.g.
> offsets to static variables are relative to the start of the data
> segment *for that module before linking*. This information is
> painfully squirreled away in the ELF symbol table as local symbols
> with wierd names. Go get 'em when needed. */
>
> dbxread.c:
>
> #ifdef HAVE_ELF
> /* If we're handling an ELF file, drag some section-relocation info
> for this source file out of the ELF symbol table, to compensate for
> Sun brain death. This replaces the section_offsets in this psymtab,
> if successful. */
> elfstab_offset_sections (objfile, result);
> #endif
>
> N.B. I'm not suggesting remove stabs support, just this hack for Sun stabs.
>
> Deleting partial_symtab.section_offsets will simplify some code
> (for non-sun-stabs it's just a pointer to objfile->section_offsets).
> It'll also help the ObjfileSplitting project.
> https://sourceware.org/gdb/wiki/ObjfileSplitting
Heh. Gotta love single stepping through code to see what's REALLY going on.
I found this testcase in gas and hacked it to compile on x86.
gas/testsuite/gas/sparc-solaris/sol-cc.s
I then walked through gdb to verify it was properly handling
this hack for Sun stabs.
But when I get to elfstab_offset_sections, sectinfo is NULL
so there is nothing to do. From the testcase clearly that's wrong.
struct stab_section_info *maybe = dbx->stab_section_info;
(top-gdb) p maybe
$17 = (struct stab_section_info *) 0x0
It turns out the data is being freed
before elfstab_offset_sections is called!
elf_read_minimal_symbols has this:
make_cleanup (free_elfinfo, (void *) objfile);
and free_elfinfo is this:
static void
free_elfinfo (void *objp)
{
struct objfile *objfile = (struct objfile *) objp;
struct dbx_symfile_info *dbxinfo = DBX_SYMFILE_INFO (objfile);
struct stab_section_info *ssi, *nssi;
ssi = dbxinfo->stab_section_info;
while (ssi)
{
nssi = ssi->next;
xfree (ssi);
ssi = nssi;
}
dbxinfo->stab_section_info = 0; /* Just say No mo info about this. */
}
So this hack is currently a no-op: we collect the needed info here:
elfread.c:
if (strcmp ("Bbss.bss", sym->name) == 0)
special_local_sect = SECT_OFF_BSS (objfile);
else if (strcmp ("Ddata.data", sym->name) == 0)
special_local_sect = SECT_OFF_DATA (objfile);
else if (strcmp ("Drodata.rodata", sym->name) == 0)
special_local_sect = SECT_OFF_RODATA (objfile);
and then throw it away (in free_elfinfo) before we use it
(in elfstab_offset_sections).
IIUC, and assuming I'm not missing anything,
this has been broken since at least gdb 7.0 (I didn't
check back any further).
The code was a little different back then, but the free_elfinfo
cleanup was still done before building psymtabs.
Sufficient motivation for deleting this code now?