This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: combreloc
- To: binutils at sourceware dot cygnus dot com
- Subject: Re: combreloc
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 24 Sep 2001 10:51:15 +0200
- References: <20010924105220.A3143@bubble.sa.bigpond.net.au>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Mon, Sep 24, 2001 at 10:52:20AM +0930, Alan Modra wrote:
> Hi Jakub,
> I've been looking at what needs to be done to make elf32-hppa support
> "combreloc". elf32-hppa doesn't use a *_RELATIVE reloc for relocations
> that are relative to the base of the shared library; Instead, we use
> normal relocs with a symbol index of zero. That presents a problem
> with the elf_backend_reloc_type_class interface as I need to look at
> more than just the reloc type. Easily fixed with the attached patch.
>
> Now I have a small problem with reloc_class_plt, as some of these relocs
> can belong to reloc_class_relative as well (.plt entries for local
> functions), but can't see any code in binutils that makes use of
> reloc_class_plt. Did this class leak in from your dynamic linker work,
> or do you have some future use in mind?
What I had in mind is when there are e.g. 3 relocs against symbol foo
and -z combreloc would sort them without taking care the PLT and COPY status:
00135df8 62301 R_386_32 0007c2d0 _IO_file_read
00135e58 62307 R_386_JUMP_SLOT 0007c2d0 _IO_file_read
00135f78 62301 R_386_32 0007c2d0 _IO_file_read
(ie. if R_SYM is equal, sort by increasing r_offset), dynamic linker's
lookup cache could not be used.
This won't happen on most arches where PLT relocs are put into special
.rel{,a}.plt (resp. .rela.IA_64.pltoff), that's why the check slipped from
binutils patch. But now when IA-64 uses R_IA64_IPLT?SB relocs even in
.rela.dyn section I'll have to add it...
Anyway, if you have a relative PLT reloc (where PLT reloc means don't
resolve to SHN_UNDEF symbol), then you should return relative.
Looking at sysdeps/hppa/dl-machine.h, if R_SYM is 0 (which is a STB_LOCAL
symbol), it will resolve to that symbol (ie. 0 + l_addr), so it definitely
is not elf_machine_type_class() == ELF_RTYPE_CLASS_PLT type of lookup.
BTW: You'll need to fix sysdeps/hppa/dl-machine.h for this change -
implement elf_machine_rela_relative(), otherwise -z combreloc linked libs will
not work with recent glibc.
Jakub