From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10041 invoked by alias); 15 Apr 2005 12:19:21 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 9835 invoked from network); 15 Apr 2005 12:19:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 15 Apr 2005 12:19:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DMPmx-0005xP-FU; Fri, 15 Apr 2005 08:19:11 -0400 Date: Fri, 15 Apr 2005 12:19:00 -0000 From: Daniel Jacobowitz To: Paul Brook , binutils@sources.redhat.com Subject: Re: [patch] VxWorks x86 shared library support. Message-ID: <20050415121911.GA22552@nevyn.them.org> Mail-Followup-To: Paul Brook , binutils@sources.redhat.com References: <200504141458.26110.paul@codesourcery.com> <20050415070921.GI31303@bubble.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415070921.GI31303@bubble.modra.org> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00420.txt.bz2 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