public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: "Nick Clifton" <nickc@redhat.com>
Cc: <binutils@sourceware.org>
Subject: Re: ld's targets vs emulations (intending to link EFI binaries	 on Linux)
Date: Fri, 13 May 2011 06:54:00 -0000	[thread overview]
Message-ID: <4DCCF1C10200007800041295@vpn.id2.novell.com> (raw)
In-Reply-To: <4DCBBEE6.5090303@redhat.com>

>>> On 12.05.11 at 13:05, Nick Clifton <nickc@redhat.com> 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=i386-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="bfd_elf32_i386_vec i386linux_vec i386pei_vec 
> x86_64pei_vec bfd_elf64_l1om_vec"
>>       want64=true
>>       ;;
>> -  x86_64-*-mingw*)
>> +  x86_64-*-mingw* | x86_64-*-pe | x86_64-*-pep )
>>       targ_defvec=x86_64pe_vec
>>       targ_selvecs="x86_64pe_vec x86_64pei_vec bfd_elf64_x86_64_vec 
> bfd_elf64_l1om_vec i386pe_vec i386pei_vec bfd_elf32_i386_vec"
>>       want64=true
>> --- binutils-2.21/ld/configure.tgt
>> +++ 2.21/ld/configure.tgt
>> @@ -274,6 +274,9 @@ i[3-7]86-*-cygwin*)	targ_emul=i386pe ;
>>   			test "$targ" != "$host"&&  LIB_PATH='${tooldir}/lib/w32api' ;;
>>   i[3-7]86-*-mingw32*)	targ_emul=i386pe ;
>>   			targ_extra_ofiles="deffilep.o pe-dll.o" ;;
>> +x86_64-*-pe | x86_64-*-pep) targ_emul=i386pep ;
>> +			targ_extra_emuls=i386pe ;
>> +			targ_extra_ofiles="deffilep.o pep-dll.o pe-dll.o" ;;
>>   x86_64-*-mingw*)	targ_emul=i386pep ;
>>   			targ_extra_emuls=i386pe
>>   			targ_extra_ofiles="deffilep.o pep-dll.o pe-dll.o" ;;
> 
> 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).
> 
> Hmm, well you are welcome to try it out, but I think that you will start 
> 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

      reply	other threads:[~2011-05-13  6:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02  7:44 Jan Beulich
2011-05-10 16:28 ` Nick Clifton
2011-05-11  6:59   ` Jan Beulich
2011-05-12 11:04     ` Nick Clifton
2011-05-13  6:54       ` Jan Beulich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DCCF1C10200007800041295@vpn.id2.novell.com \
    --to=jbeulich@novell.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).