From: "H. J. Lu" <hjl@lucon.org>
To: binutils@sources.redhat.com
Subject: Re: PATCH: SHN_XINDEX support is broken
Date: Mon, 07 Feb 2005 03:41:00 -0000 [thread overview]
Message-ID: <20050206181859.GA28251@lucon.org> (raw)
In-Reply-To: <20050206131810.GB23954@bubble.modra.org>
On Sun, Feb 06, 2005 at 11:48:10PM +1030, Alan Modra wrote:
>
> "SHT_GROUP sections are typically ordered before SHT_SYMTAB and
> SHT_SYMTAB_SHNDX in the ELF section headers, and thus are loaded by
> elf_object_p before the symbol table sections. When loading a group
> section, bfd_section_from_shdr calls group_signature to read a symbol
> name associated with the group. group_signature ensures that the
> SHT_SYMTAB section is loaded, but doesn't load SHT_SYMTAB_SHNDX. This
> can lead to an abort if the symbol st_shndx is SHN_XINDEX."
>
> > > It only works without SHN_XINDEX
> > > since SHT_REL/SHT_RELA sections will load SHT_SYMTAB. The problem
> > > affects both bfd and readelf. I will see what I can do.
> > >
> >
> > 2005-02-04 H.J. Lu <hongjiu.lu@intel.com>
> >
> > * elfcode.h (elf_object_p): Read in SHT_SYMTAB and
> > SHT_SYMTAB_SHNDX sections first.
>
> I don't think this is the best place to fix this problem. One reason is
> that elfcode.h is compiled twice, once for 32-bit support and once for
> 64-bit, so we should avoid adding code to elfcode.h if at all possible.
> Another reason is that bfd_section_from_shdr already handles a number of
> similar section dependecies, so that's where I would add code to load
> SHT_SYMTAB_SHNDX when handling SHT_SYMTAB.
>
> Like this. Plus a few cleanups and minor optimizations. I'll commit in
> the morning assuming my overnight tests look good.
>
> * elf-bfd.h (elf_string_from_elf_strtab): Delete macro.
> * elf.c (bfd_elf_string_from_elf_section): Expand occurrence of
> elf_string_from_elf_strtab.
> (_bfd_elf_setup_group_pointers, bfd_section_from_shdr): Likewise.
> (bfd_section_from_shdr): For SHT_SYMTAB, load SHT_SYMTAB_SHNDX too
> if it exists. Don't do the reverse for SHT_SYMTAB_SHNDX. For
> SHT_STRTAB, check whether the strtab is for symtab or dynsymtab by
> looking at cached symtab info first, before iterating over headers.
> For SHT_REL and SHT_RELA, load dynsymtab if needed.
> * elfcode.h (elf_object_p): Don't load section header stringtab
> specially.
>
I have been looking at the change. I am not 100% sure if it will be
always correct. Will the symbol table be read in by SHT_REL/SHT_RELA?
What if a file doesn't have them and does have SHT_GROUP? I will try
to come up with a testcase for that.
H.J.
next prev parent reply other threads:[~2005-02-06 18:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-06 7:14 H. J. Lu
2005-02-06 7:24 ` PATCH: " H. J. Lu
2005-02-06 10:04 ` H. J. Lu
2005-02-06 15:03 ` Alan Modra
2005-02-07 2:30 ` H. J. Lu
2005-02-07 3:41 ` H. J. Lu [this message]
2005-02-07 16:01 ` Alan Modra
2005-02-06 10:02 ` H. J. Lu
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=20050206181859.GA28251@lucon.org \
--to=hjl@lucon.org \
--cc=binutils@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).