You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of developing MultiArchUefiPkg we've seen UEFI apps (thankfully not drivers...yet) that are not 64-bit clean:
Treating stack (ESP) as 32-bit
Corrupting AllocatePool pointers to be non-64-bit clean
This appears on a system where UEFI prefers memory > 4GiB. MultiArchUefiPkg already tries putting the emulated stack below 4GiB if possible, and with #5 could also try keeping pool/page allocations below 4GiB as well.
For consistency, it could be interesting if the images themselves were loaded below 4GiB if that were available, i.e. if the whole emulated image handling by DXE supported taking a hint and then reloading the image. Maybe, just try loading the image first below 4GiB regardless if the image type is x64. This could be an EDK2 patch...
The text was updated successfully, but these errors were encountered:
As part of developing MultiArchUefiPkg we've seen UEFI apps (thankfully not drivers...yet) that are not 64-bit clean:
This appears on a system where UEFI prefers memory > 4GiB. MultiArchUefiPkg already tries putting the emulated stack below 4GiB if possible, and with #5 could also try keeping pool/page allocations below 4GiB as well.
For consistency, it could be interesting if the images themselves were loaded below 4GiB if that were available, i.e. if the whole emulated image handling by DXE supported taking a hint and then reloading the image. Maybe, just try loading the image first below 4GiB regardless if the image type is x64. This could be an EDK2 patch...
The text was updated successfully, but these errors were encountered: