PATCH: PR ld/10337: strip breaks statically linked binaries with .rela.plt section

[H.J. Lu]

On Wed, Jul 1, 2009 at 12:01 AM, Alan Modra<amodra@bigpond.net.au> wrote:
> 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.
>

All reloc sections pointing to the dynamic symbol table
are treated as normal sections. Before STT_GNU_IFUNC
changes, we never had executables with reloc section
which didn't point to the dynamic symbol table. Now
static executables with  STT_GNU_IFUNC symbols may
have such reloc section. I believe all reloc sections in
executables and shared libraries should be treated as
normal sections. As for "objcopy --adjust-vma", if it
works before on executables, it should still work now.


-- 
H.J.