* edk2 memory map on QEMU
@ 2021-07-30 19:32 Stuart Yoder
2021-07-30 20:36 ` [edk2-devel] " Andrew Fish
0 siblings, 1 reply; 3+ messages in thread
From: Stuart Yoder @ 2021-07-30 19:32 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
I am playing around with EDK2 on QEMU with a UEFI shell application and in the app I allocate some memory using gBS->AllocatePool(EfiBootServicesData, ...)
Programmatically accessing the pointer returned works fine, but when I print it, it does not seem to be what I would expect is a valid address.
I've allocated 4GB to the QEMU machine, which I believe starts at 0x40000000.
But, when I print the address returned by AllocatePool the value is "0x39177018".
I thought that all memory was identity mapped where phys=virt, so not sure where the 0x39177018 is coming from. Trying to dump 0x39177018 from the QEMU console or GDB results in a bad address error.
Thanks,
Stuart
[-- Attachment #2: Type: text/html, Size: 967 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [edk2-devel] edk2 memory map on QEMU
2021-07-30 19:32 edk2 memory map on QEMU Stuart Yoder
@ 2021-07-30 20:36 ` Andrew Fish
2021-07-30 21:50 ` Stuart Yoder
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Fish @ 2021-07-30 20:36 UTC (permalink / raw)
To: edk2-devel-groups-io, stuart.yoder
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
> On Jul 30, 2021, at 12:32 PM, Stuart Yoder <stuart.yoder@arm.com> wrote:
>
> I am playing around with EDK2 on QEMU with a UEFI shell application and in the app I allocate some memory using gBS->AllocatePool(EfiBootServicesData, ...)
>
> Programmatically accessing the pointer returned works fine, but when I print it, it does not seem to be what I would expect is a valid address.
>
> I've allocated 4GB to the QEMU machine, which I believe starts at 0x40000000.
>
You can run the `memmap` command at the EFI Shell to see the layout.
> But, when I print the address returned by AllocatePool the value is "0x39177018".
>
Print != printf on some of the format string so be careful about that….
Thanks,
Andrew Fish
> I thought that all memory was identity mapped where phys=virt, so not sure where the 0x39177018 is coming from. Trying to dump 0x39177018 from the QEMU console or GDB results in a bad address error.
> Thanks,
> Stuart
>
[-- Attachment #2: Type: text/html, Size: 2142 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [edk2-devel] edk2 memory map on QEMU
2021-07-30 20:36 ` [edk2-devel] " Andrew Fish
@ 2021-07-30 21:50 ` Stuart Yoder
0 siblings, 0 replies; 3+ messages in thread
From: Stuart Yoder @ 2021-07-30 21:50 UTC (permalink / raw)
To: Andrew Fish, edk2-devel-groups-io
On 7/30/21 3:36 PM, Andrew Fish wrote:
>
>
>> On Jul 30, 2021, at 12:32 PM, Stuart Yoder <stuart.yoder@arm.com <mailto:stuart.yoder@arm.com>> wrote:
>>
>> I am playing around with EDK2 on QEMU with a UEFI shell application and in the app I allocate some memory using gBS->AllocatePool(EfiBootServicesData, ...)
>>
>> Programmatically accessing the pointer returned works fine, but when I print it, it does not seem to be what I would expect is a valid address.
>>
>> I've allocated 4GB to the QEMU machine, which I believe starts at 0x40000000.
>>
>
> You can run the `memmap` command at the EFI Shell to see the layout.
>
>> But, when I print the address returned by AllocatePool the value is "0x39177018".
>>
>
> Print != printf on some of the format string so be careful about that….
>
I figured it out. It was a dumb Print() formatting error that resulted in
the address getting truncated to 8 bytes.
Thanks,
Stuart
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-07-30 21:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-30 19:32 edk2 memory map on QEMU Stuart Yoder
2021-07-30 20:36 ` [edk2-devel] " Andrew Fish
2021-07-30 21:50 ` Stuart Yoder
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox