Integer assignment yields unexpected results in ACPICA code
Posted: Sun May 23, 2021 10:29 am
So i've been porting ACPICA recently and up to this moment everything was going pretty well. A few tweaks here and there, a bit of time spent reading documentation - nothing unusual. However, what i saw next made me wonder for a few days. I never encountered anything like that.
There is this perfectly normal integer assignment at tables/tbutils.c that just doesn't work. I think it's better to just show my GDB session logs.
(i use qemu+gdb as described in: https://wiki.osdev.org/Kernel_Debugging ... _with_QEMU)
You can clearly see here when i start "si"-ing, the instruction that is evidently supposed to place 0x7fe18fe to eax, somehow places 0 instead.
I tried:
- using 32-bit ACPI_PHYSICAL_ADDRESS by defining ACPI_32BIT_PHYSICAL_ADDRESS
- updating my cross-compiler
- various hack combinations, like using memcpy instead
- disabling caching of virtual memory that RSDP gets mapped to
Nothing works.
Also i tried using kprintf to output values before and after assignment. It gaves the following output both on qemu and real hardware, with 32-bit or 64-bit ACPI_PHYSICAL_ADDRESS:
RSDP is located and verified correctly in the previous step (it uses AcpiFindRootPointer() to do so). I used kprintf() to output Rsdp->RsdtPhysicalAddress at that point and all works as expected.
RSDP memory region then gets unmapped and mapped at AcpiTbParseRootTable() again. And then it's already like that.
I have no assumptions about what might cause this and where to look for any hints. Any help would be much appreciated.
Here is the link to the file in ACPICA github repo where this assignment is located: https://github.com/acpica/acpica/blob/m ... /tbutils.c, line 432.
There is this perfectly normal integer assignment at tables/tbutils.c that just doesn't work. I think it's better to just show my GDB session logs.
(i use qemu+gdb as described in: https://wiki.osdev.org/Kernel_Debugging ... _with_QEMU)
Code: Select all
(gdb) set disassemble-next-line on
(gdb) set disassembly-flavor intel
(gdb) where
#0 AcpiTbParseRootTable (RsdpAddress=1006368) at acpica/tables/tbutils.c:432
#1 0xc004a83a in AcpiInitializeTables (InitialTableArray=0x0, InitialTableCount=16, AllowResize=0 '\000')
at acpica/tables/tbxface.c:268
#2 0xc0002fbb in acpi_do_sth () at kernel/kmain.c:42
#3 0xc0003115 in kmain (mb_info=0x9500, mb_magic=732803074) at kernel/kmain.c:80
#4 0xc0002885 in start_hhalf () at kernel/start.s:41
(gdb) f
#0 AcpiTbParseRootTable (RsdpAddress=1006368) at acpica/tables/tbutils.c:432
432 Address = (ACPI_PHYSICAL_ADDRESS) Rsdp->RsdtPhysicalAddress;
=> 0xc004aaf9 <AcpiTbParseRootTable+163>: 8b 45 e0 mov eax,DWORD PTR [ebp-0x20]
0xc004aafc <AcpiTbParseRootTable+166>: 8b 40 10 mov eax,DWORD PTR [eax+0x10]
(gdb) p sizeof(Address)
$1 = 8
(gdb) p sizeof(Rsdp->RsdtPhysicalAddress)
$2 = 4
(gdb) p &Address
$3 = (ACPI_PHYSICAL_ADDRESS *) 0xc003ffc8
(gdb) p &Rsdp->RsdtPhysicalAddress
$4 = (UINT32 *) 0xc0054b30
(gdb) p Rsdp
$5 = (ACPI_TABLE_RSDP *) 0xc0054b20
(gdb) p/x Rsdp->RsdtPhysicalAddress
$6 = 0x7fe18fe
(gdb) i r ebp
ebp 0xc003ffe0 0xc003ffe0
(gdb) i r eax
eax 0x0 0
(gdb) si
0xc004aafc 432 Address = (ACPI_PHYSICAL_ADDRESS) Rsdp->RsdtPhysicalAddress;
0xc004aaf9 <AcpiTbParseRootTable+163>: 8b 45 e0 mov eax,DWORD PTR [ebp-0x20]
=> 0xc004aafc <AcpiTbParseRootTable+166>: 8b 40 10 mov eax,DWORD PTR [eax+0x10]
(gdb) i r eax
eax 0xc0054b20 -1073394912
(gdb) si
432 Address = (ACPI_PHYSICAL_ADDRESS) Rsdp->RsdtPhysicalAddress;
=> 0xc004aaff <AcpiTbParseRootTable+169>: 89 45 e8 mov DWORD PTR [ebp-0x18],eax
0xc004ab02 <AcpiTbParseRootTable+172>: c7 45 ec 00 00 00 00 mov DWORD PTR [ebp-0x14],0x0
(gdb) i r eax
eax 0x0 0
(gdb) si
0xc004ab02 432 Address = (ACPI_PHYSICAL_ADDRESS) Rsdp->RsdtPhysicalAddress;
0xc004aaff <AcpiTbParseRootTable+169>: 89 45 e8 mov DWORD PTR [ebp-0x18],eax
=> 0xc004ab02 <AcpiTbParseRootTable+172>: c7 45 ec 00 00 00 00 mov DWORD PTR [ebp-0x14],0x0
(gdb) si
433 TableEntrySize = ACPI_RSDT_ENTRY_SIZE;
=> 0xc004ab09 <AcpiTbParseRootTable+179>: c7 45 f4 04 00 00 00 mov DWORD PTR [ebp-0xc],0x4
(gdb) p/x Address
$8 = 0x0
I tried:
- using 32-bit ACPI_PHYSICAL_ADDRESS by defining ACPI_32BIT_PHYSICAL_ADDRESS
- updating my cross-compiler
- various hack combinations, like using memcpy instead
- disabling caching of virtual memory that RSDP gets mapped to
Nothing works.
Also i tried using kprintf to output values before and after assignment. It gaves the following output both on qemu and real hardware, with 32-bit or 64-bit ACPI_PHYSICAL_ADDRESS:
Code: Select all
&Rsdp->RsdtPhysicalAddress == 0xc0054b30
before assignment: Rsdp->RsdtPhysicalAddress == 0x0
after assignment: Address == 0x0; Rsdp->RsdtPhysicalAddress == 0x0
RSDP memory region then gets unmapped and mapped at AcpiTbParseRootTable() again. And then it's already like that.
I have no assumptions about what might cause this and where to look for any hints. Any help would be much appreciated.
Here is the link to the file in ACPICA github repo where this assignment is located: https://github.com/acpica/acpica/blob/m ... /tbutils.c, line 432.