ld's targets vs emulations (intending to link EFI binaries on Linux)

ld's targets vs emulations (intending to link EFI binaries on Linux)

[Jan Beulich]

What is the point of ld supporting (in e.g. the default x86 Linux
configurations) PE executables as targets, but not as emulations?
This basically means that one can link such executables, but there's
no control over the various linking parameters (as those are
processed by the respective [not present] emulation code).

Note that elilo, for example, is also suffering from this, working
around it by first linking an ELF shared object, then converting it
to a PE executable via objcopy. A gross hack imo, not the least
because according to what I can see, objcopy doesn't translate
relocations, requiring the produced binary to do "self relocation"
(see the gnu-efi project).

Thanks, Jan

Re: ld's targets vs emulations (intending to link EFI binaries on Linux)

[Nick Clifton]

Hi Jan,

> What is the point of ld supporting (in e.g. the default x86 Linux
> configurations) PE executables as targets, but not as emulations?
> This basically means that one can link such executables, but there's
> no control over the various linking parameters (as those are
> processed by the respective [not present] emulation code).

Essentially this is because it is easier this way.  Supporting multiple, 
dissimilar emulations would make the linker a lot more complex.

Changing the output format is actually a problematic feature of the 
linker, and one that is disabled for some architectures.  It is much 
cleaner to link without changing format and then use objcopy to convert 
the resulting binary.  You are correct however in saying that objcopy 
will not convert relocations and this is actually one of the big 
problems with format conversions - there is rarely a good mapping 
between the relocations of the formats.

Cheers
   Nick

Re: ld's targets vs emulations (intending to link EFI binaries on Linux)

[Jan Beulich]

Hi Nick,

>>> On 10.05.11 at 18:28, Nick Clifton <nickc@redhat.com> wrote:
>> What is the point of ld supporting (in e.g. the default x86 Linux
>> configurations) PE executables as targets, but not as emulations?
>> This basically means that one can link such executables, but there's
>> no control over the various linking parameters (as those are
>> processed by the respective [not present] emulation code).
> 
> Essentially this is because it is easier this way.  Supporting multiple, 
> dissimilar emulations would make the linker a lot more complex.

Reads sort of contradictory to me: The target (and hence the
output format) *is* supported, its the various special things that
can't be controlled.

Also things being easier isn't a really good reason for a partial
implementation imo.

> Changing the output format is actually a problematic feature of the 
> linker, and one that is disabled for some architectures.  It is much 
> cleaner to link without changing format and then use objcopy to convert 
> the resulting binary.  You are correct however in saying that objcopy 
> will not convert relocations and this is actually one of the big 
> problems with format conversions - there is rarely a good mapping 
> between the relocations of the formats.

Without any special relocations involved, there ought to be a pretty
clean mapping between ELF and PE relocations (on x86 at least).

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" ;;

(In the ld part I followed the model of not merging distinct entries,
albeit it would be possible to simply extend the mingw case - i386
has winnt, pe, and mingw all listed separately despite them all
specifying exactly the same.)

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

Thanks, Jan

Re: ld's targets vs emulations (intending to link EFI binaries on Linux)

[Nick Clifton]

Hi Jan,

> 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,


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

Cheers
   Nick

Re: ld's targets vs emulations (intending to link EFI binaries on Linux)

[Jan Beulich]

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