Re: [patch] VxWorks x86 shared library support.

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 15, 2005 at 04:39:21PM +0930, Alan Modra wrote:
> I don't like any of your hacks to the generic ELF linker code.  With a
> little thought, you should be able to eliminate most of them.

FWIW, I'll take blame for most of the gross common ELF bits.  They're
much prettier when Paul posted them than when I got through with them,
though.

> On Thu, Apr 14, 2005 at 02:58:25PM +0100, Paul Brook wrote:
> > 	* elf-bfd.h (struct elf_backend_data): Add is_vxworks.
> > 	(RELOC_FOR_GLOBAL_SYMBOL): Ignore VxWorks magic GOT symbols.
> 
> 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.

> > 	(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.

I suppose it could be a backend hook and defined by the various VxWorks
backends...

-- 
Daniel Jacobowitz
CodeSourcery, LLC