Re: [patch] VxWorks x86 shared library support.

[Alan Modra <amodra at bigpond dot net dot au>]

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