Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: gdb-patches@sourceware.org
Subject: [RFC] When can we remove Sun-specific stabs support? (when will it be ok to delete partial_symtab.section_offsets?)
Date: Thu, 07 May 2015 21:21:00 -0000	[thread overview]
Message-ID: <90e6ba6e87129285600515847ec6@google.com> (raw)

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


             reply	other threads:[~2015-05-07 21:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-07 21:21 Doug Evans [this message]
2015-05-07 22:52 ` Doug Evans
2015-05-07 23:04   ` Doug Evans
2015-05-08 10:47     ` Pedro Alves

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=90e6ba6e87129285600515847ec6@google.com \
    --to=dje@google.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