From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14476 invoked by alias); 13 May 2011 06:54:44 -0000 Received: (qmail 14465 invoked by uid 22791); 13 May 2011 06:54:43 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vpn.id2.novell.com (HELO vpn.id2.novell.com) (195.33.99.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 May 2011 06:54:29 +0000 Received: from EMEA1-MTA by vpn.id2.novell.com with Novell_GroupWise; Fri, 13 May 2011 07:54:27 +0100 Message-Id: <4DCCF1C10200007800041295@vpn.id2.novell.com> Date: Fri, 13 May 2011 06:54:00 -0000 From: "Jan Beulich" To: "Nick Clifton" Cc: Subject: Re: ld's targets vs emulations (intending to link EFI binaries on Linux) References: <4DBE7CE2020000780003F1C6@vpn.id2.novell.com> <4DC967BE.2020201@redhat.com> <4DCA4FCA0200007800040E98@vpn.id2.novell.com> <4DCBBEE6.5090303@redhat.com> In-Reply-To: <4DCBBEE6.5090303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00187.txt.bz2 >>> On 12.05.11 at 13:05, Nick Clifton wrote: Hi Nick, >> Anyway, while for i386 to build a linker that can build both ELF >> and full-featured PE, all it takes is an extra configure option >> (--enable-target=3Di386-pe or some such), for x86-64 to be able >> to do the same one needs to first introduce such a bfd and >> linker target. Would a change like the below be acceptable for >> mainline? >> >> --- binutils-2.21/bfd/config.bfd >> +++ 2.21/bfd/config.bfd >> @@ -632,7 +632,7 @@ case "${targ}" in >> targ_selvecs=3D"bfd_elf32_i386_vec i386linux_vec i386pei_vec=20 > x86_64pei_vec bfd_elf64_l1om_vec" >> want64=3Dtrue >> ;; >> - x86_64-*-mingw*) >> + x86_64-*-mingw* | x86_64-*-pe | x86_64-*-pep ) >> targ_defvec=3Dx86_64pe_vec >> targ_selvecs=3D"x86_64pe_vec x86_64pei_vec bfd_elf64_x86_64_vec=20 > bfd_elf64_l1om_vec i386pe_vec i386pei_vec bfd_elf32_i386_vec" >> want64=3Dtrue >> --- binutils-2.21/ld/configure.tgt >> +++ 2.21/ld/configure.tgt >> @@ -274,6 +274,9 @@ i[3-7]86-*-cygwin*) targ_emul=3Di386pe ; >> test "$targ" !=3D "$host"&& LIB_PATH=3D'${tooldir}/lib/w32api' ;; >> i[3-7]86-*-mingw32*) targ_emul=3Di386pe ; >> targ_extra_ofiles=3D"deffilep.o pe-dll.o" ;; >> +x86_64-*-pe | x86_64-*-pep) targ_emul=3Di386pep ; >> + targ_extra_emuls=3Di386pe ; >> + targ_extra_ofiles=3D"deffilep.o pep-dll.o pe-dll.o" ;; >> x86_64-*-mingw*) targ_emul=3Di386pep ; >> targ_extra_emuls=3Di386pe >> targ_extra_ofiles=3D"deffilep.o pep-dll.o pe-dll.o" ;; >=20 > This is OK, Thanks, committed. >> What the original question boils down to is whether i386 and x86_64 >> Linux selections shouldn't default to enable PE emulations (and not >> just the respective BFD targets). >=20 > Hmm, well you are welcome to try it out, but I think that you will start= =20 > to run into problems with the relocations. Sure, it won't work any better than it does when enabling the extra emulation on the configure command line (and it's not just the relocations - I also notice that all non-global symbols get lost). When I can spare some cycles for this, I'd certainly be interested in improving the situation. The question just was whether that enabling shouldn't be the default irrespective of the current shortcomings (eventually for all architectures that support Linux booting from EFI). Jan