This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: PR ld/10337: strip breaks statically linked binaries with .rela.plt section
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 1 Jul 2009 16:31:16 +0930
- Subject: Re: PATCH: PR ld/10337: strip breaks statically linked binaries with .rela.plt section
- References: <20090627155720.GA21031@lucon.org> <20090630005136.GQ3861@bubble.grove.modra.org> <6dc9ffc80906291800l1cb98aa2id3d35986cd5e4716@mail.gmail.com>
On Mon, Jun 29, 2009 at 06:00:40PM -0700, H.J. Lu wrote:
> On Mon, Jun 29, 2009 at 5:51 PM, Alan Modra<amodra@bigpond.net.au> wrote:
> > On Sat, Jun 27, 2009 at 08:57:20AM -0700, H.J. Lu wrote:
> >> 2. We use
> >>
> >> hdr->sh_link != elf_onesymtab (abfd)
> >>
> >> to check if sh_link points to the main symbol table. But SHN_UNDEF
> >> will never be the main symbol table.
> >>
> >> This patch fixes it with a testcase. I will check it in as an obvious
> >> fix.
> >
> > I think this change is wrong. ?If you treat relocation sections as
> > normal sections then you lose all the special BFD processing of
> > relocs. ?For example, objcopy --adjust-vma on an executable will not
> > modify reloc addresses for you. ?How hard is it to support reloc
> > sections with no associated symbol table?
> >
>
> Do you have a testcase? How does "objcopy --adjust-vma"
> work without relocation info? All the addresses in executable
> will be wrong.
No, I don't have a testcase. My example was a poor one as far as
usefulness goes. It was just meant to illustrate that reloc sections
are treated specially. I still think you should investigate removing
your hack.
--
Alan Modra
Australia Development Lab, IBM