On 07.08.2024 15:48, Alejandro Vallejo wrote:
> If code is loaded by EFI the loader will relocate the image
> under 4GB.
This is the MB2 EFI path you're talking about? Since there are two paths,
I think this needs clearly separating in all descriptions.
If it is the MB2 path, then "relocate" isn't quite correct, I think:
Relocations aren't applied in that case, as none are present in xen.gz.
I'd rather call this "put at an address below 4G". However, that isn't
any different from the non-EFI MB1/2 paths, is it? I feel like I'm
missing something here.
> This cause offsets in x86 code generated by
> sym_offs(SYMBOL) to be relocated too (basically they won't be
> offsets from image base). In order to get real offset the
> formulae "sym_offs(SYMBOL) - sym_offs(__image_base__)" is
> used instead.
The main calculations of %esi are, if I'm not mistaken,
/* Store Xen image load base address in place accessible for 32-bit
code. */
lea __image_base__(%rip),%esi
and
/* Calculate the load base address. */
call 1f
1: pop %esi
sub $sym_offs(1b), %esi
i.e. both deliberately %rip-relative to be position-independent. What's
wrong with this?
There are many more uses of sym_esi(). Why is it only this single one
which poses a problem?
> Also, in some case %esi register (that should point to
> __image_base__ addresss) is not set so compute in all cases.
Which "some case" is this?
> Code tested forcing failures in the code.
>
> Signed-off-by: Frediano Ziglio <frediano.zig...@cloud.com>
No Fixes: tag?
Jan
