Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.18 at 18:43, <julien.grall@xxxxxxxxxx> wrote:
> On 12/01/18 13:13, Jan Beulich wrote:
>>>>> On 09.01.18 at 20:43, <julien.grall@xxxxxxxxxx> wrote:
>>> When I compiled the snippet on x86 and Arm, no relocation is available
>>> for the pointers to string in the array in the final binary. Yet they
>>> are available in the object.
>> 
>> I can see them there in the binary I look at. I use my own tool
>> for dumping, so the output may look unfamiliar to you, but here
>> are the relevant pieces:
> 
> I am a bit confused. Which binary are you looking at? Is it xen.efi?
> I don't seem to find them in xen-syms.

Of course it is xen.efi. xen-syms can't possibly have any PE relocations,
as it's an ELF image on x86.

>> Well, without having seen the binary I don't think I can conclude
>> in the direction of compiler bug. Please don't forget that ld itself
>> does indeed not (yet) create any relocations in PE executables
>> (which an EFI application is). They're being added in a post-
>> processing step (hence the need to link the binary twice at
>> different base addresses, for the helper tool [mkreloc] to figure
>> out where relocations are needed).
> 
> If the code compiled is position independent, then you should not need
> relocation. Right? So what are you trying to achieve with mkreloc?

If _all_ of the code, even assembly, was position independent,
then yes, there shouldn't be relocations. But that's not the case
right now.

> Also, it does not explain why the compiler is issuing absolute address 
> when building with -fpie.

To be honest I'm not certain what guarantees -fpie makes on the
compiled code. It looks to me as if it only tries to minimize the
relocations needed, not eliminate all of them (after all the binary
will work fine that way, it is just required that the relocations not
be removed while linking the final binary). Indeed both 32-bit and
64-bit for both x86 and ARM produce relocations for tables like
the one we talk about (so called absolute ones on ARM), yet I
don't think this is a compiler bug.

>>> So I am wondering how this work on x86? Note that this code is only used
>>> in error path.
>> 
>> Sure, but an error path is being taken every now and then, and
>> I personally have seen errors coming back (mostly after having
>> made mistakes elsewhere).
> 
> And I guess the binary will never be loaded at the same as virtual 
> address as Xen would be meant to run?

Indeed - it can't be loaded at that address, as the 1:1 mapping the
EFI environment requires can't ever have any present mappings in
the upper half of the virtual address space.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel