This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] VxWorks x86 shared library support.
On Fri, Apr 15, 2005 at 08:19:11AM -0400, Daniel Jacobowitz wrote:
> On Fri, Apr 15, 2005 at 04:39:21PM +0930, Alan Modra wrote:
> > No way is this RELOC_FOR_GLOBAL_SYMBOL hack acceptable. Instead, do
> > something about giving these magic symbols a value. See, for example,
> > elf32_hppa_set_gp.
>
> Won't this cause the symbols to be output as defined? The loader
> requires them to be undefined.
Yes, it would output them as defined if you did it the same place as
elf32_hppa_set_gp. I didn't realize you wanted them undefined. I
suppose you could put a hack in elf_backend_output_arch_syms to define
the sym for use by relocate_section.
> > > (elf_link_adjust_relocs): Convert SHN_UNDEF relocs for PLT stubs
> > > into section relative relocs.
> >
> > Yikes! You say
> >
> > + /* This is a relocation from an executable or shared library
> > + against a symbol in a different shared library. We are
> > + createing a definition in the output file but it does not come
> > + from any of out normal (.o) files. ie. a PLT stub.
> >
> > So this is presumably a linker created reloc. Why can't you create it
> > such that it doesn't need this horrible hack?
>
> No, it isn't linker created. VxWorks executables are kind of odd; they
> are linked using --emit-relocs, and both the dynamic and non-dynamic
> relocations are required for proper loading. What this bit is doing is
> fixing up relocations from an input file that would otherwise be copied
> straight to the output file. They're reloaded from the input file
> here, so this is the only place the linker has an opportunity to frob
> them.
No, they are loaded from memory, where they have been written by
_bfd_elf_link_output_relocs, or elf_backend_emit_relocs. Please look at
putting any reloc twiddles into a backend_emit_relocs functions.
--
Alan Modra
IBM OzLabs - Linux Technology Centre