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. > 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? Why would it help if the relocations were placed in .data? 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. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#48901): https://edk2.groups.io/g/devel/message/48901 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] -=-=-=-=-=-=-=-=-=-=-=-
