> On Oct 14, 2019, at 6:11 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>
> On 10/12/19 08:42, Andrew Fish wrote:
>> Laszlo,
>>
>> For 2) this is very unfortunate. I think the root cause is for those
>> of us who work on x86 hardware day to day we get programed that
>> SEC/PEI is IA32 and DXE is X64, and this can lead to some unfortunate
>> coding outcomes.
>
> First I was confused by this; I didn't understand why the "bitness" of
> SEC/PEI mattered here.
>
> But, of course, you are right: if SEC/PEI are 32-bit, then the
> problematic relocations are never generated by the compiler in the first
> place.
>
Laszlo,
The other "human" problem is people assume DXE always runs from memory so they
think that patching is OK. I've even see people use IA32 to mean PEI on X64
platforms. So the implementation (32-bit PEI) leaks into the architecture.
>> I'm guessing this code probably got ported from the DXE CPU driver or
>> some other place that had no XIP assumptions. One option vs. patching
>> is putting the relocations in the .data section. The only issue with
>> that could be the need to align sections on page boundaries and that
>> may take up too much space in XIP code. Perhaps we could only require
>> the .data section relocations for XCODE, and map them to .text for
>> the other toolchain?
>
> In SEC, all sections of the binary are located in flash, aren't they?
Yes.
> Why would it help if the relocations were placed in .data?
Sorry if I was unclear. The Xcode linker (ld64) enforces a macOS x86_64 ABI
that makes it so even the image loader can't write the text section. Thus you
can't link an image that has relocations in the text section, and there is no
flag to ld64 to turn this behavior off. So the workaround is to generate code
like the compiler and don't have any relocations in the text section. Moving
the relocation from the text to the data section is needed to make the Xcode
linker (ld64) link the code. if there are relocations in the text section then
the link will fail on Xcode builds.
When you are writing assembly code there is no restriction about placing code
in the data section. Generally we try to fix issues by converting the code to
use PC relative addressing, but a quick and dirty fix is to change the code
over to the data section. The cleaner solution is to have a global in the data
section that contains the relocatable address, and that is like the simple
example of the C code global I sent out.
> I'm reminded
> of global variables in SEC, and those are not writable in SEC either.
> (At least on QEMU.) I'm uncertain if this is somehow connected to
> Cache-as-RAM, but if it is: QEMU does not support Cache-as-RAM.
>
For SEC the relocations would have been applied at build time. The SEC will
have been linked at around zero, and when it was placed in the FV it would have
been relocated to its XIP location. For code running from memory the EFI
PE/COFF loader would apply the relocations as part of loading the image. But
non of the above works if your build fails due to a linker error :(.
Thanks,
Andrew Fish
> Thanks
> Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48935): https://edk2.groups.io/g/devel/message/48935
Mute This Topic: https://groups.io/mt/34203585/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
