On Dec 21, 2012, at 8:14 AM, Mark Cave-Ayland wrote:
On 21/12/12 13:09, Programmingkid wrote:
No, you've got this the wrong way around. The default CFLAGS for OpenBIOS uses -Os which causes heavy optimisation and confuses gdb causing it to give incorrect output. So if you want to use gdb to debug OpenBIOS, you need to rebuild it with -O0 and use the generated .nostrip unstripped binary.
I have done that and the problem is still there.
Okay - did you make sure you did a complete rebuild so the flags got picked up by the C compiler?
rm -rf obj-ppc vi Makefile.target (change -Os to -O0) ./config/scripts/switch-arch ppc make
If you're sure, post a message with detailed instructions to the list so that others can try and reproduce what you are seeing.
How to reproduce the problem: 1. Start QEMU for debugging: qemu-system-ppc -m 128 -bios openbios-qemu.elf.nostrip -cdrom darwin8.iso -s -S
2. Start up gdb to read the firmware file: powerpc-linux-gdb openbios-qemu.elf.nostrip
3. Connect to QEMU using this command inside gdb: target remote localhost:1234
4. Set a breakpoint at this place: b ofmem.c:414
5. Have OpenBIOS start the boot process by entering this in QEMU: boot cd:,\:tbxi
6. When the breakpoint in tripped, type this in gdb: print &next_grab_slot.
next_grab_slot will have an address that isn't available to QEMU. The value I see is 0xfffda060. QEMU would have to have over 4 GB of ram in order to access this address.
On 21/12/12 14:45, Programmingkid wrote:
How to reproduce the problem:
Start QEMU for debugging: qemu-system-ppc -m 128 -bios openbios-qemu.elf.nostrip -cdrom darwin8.iso -s -S
Start up gdb to read the firmware file: powerpc-linux-gdb openbios-qemu.elf.nostrip
Connect to QEMU using this command inside gdb: target remote localhost:1234
Set a breakpoint at this place: b ofmem.c:414
Have OpenBIOS start the boot process by entering this in QEMU: boot cd:,\:tbxi
When the breakpoint in tripped, type this in gdb: print&next_grab_slot.
next_grab_slot will have an address that isn't available to QEMU. The value I see is 0xfffda060. QEMU would have to have over 4 GB of ram in order to access this address.
In short, this is actually fine. You have to remember that OpenBIOS uses the MMU (emulated by QEMU) and hence physical pages can be mapped to any virtual address within the 32-bit address space of the PPC CPU.
Once the MMU is enabled in the OpenBIOS startup code, all addresses (including those used by gdb) are virtual addresses. If you want to view the current virtual to physical mappings, use the "info tlb" command from the QEMU monitor.
Note that if you try and access an unmapped address then you will normally obtain some kind of "page fault" or "TLB miss" processor exception. So if you can read and write from the variable, then everything is working correctly.
ATB,
Mark.
On Dec 24, 2012, at 6:26 AM, Mark Cave-Ayland wrote:
On 21/12/12 14:45, Programmingkid wrote:
How to reproduce the problem:
Start QEMU for debugging: qemu-system-ppc -m 128 -bios openbios-qemu.elf.nostrip -cdrom darwin8.iso -s -S
Start up gdb to read the firmware file: powerpc-linux-gdb openbios-qemu.elf.nostrip
Connect to QEMU using this command inside gdb: target remote localhost:1234
Set a breakpoint at this place: b ofmem.c:414
Have OpenBIOS start the boot process by entering this in QEMU: boot cd:,\:tbxi
When the breakpoint in tripped, type this in gdb: print&next_grab_slot.
next_grab_slot will have an address that isn't available to QEMU. The value I see is 0xfffda060. QEMU would have to have over 4 GB of ram in order to access this address.
In short, this is actually fine. You have to remember that OpenBIOS uses the MMU (emulated by QEMU) and hence physical pages can be mapped to any virtual address within the 32-bit address space of the PPC CPU.
Once the MMU is enabled in the OpenBIOS startup code, all addresses (including those used by gdb) are virtual addresses. If you want to view the current virtual to physical mappings, use the "info tlb" command from the QEMU monitor.
Note that if you try and access an unmapped address then you will normally obtain some kind of "page fault" or "TLB miss" processor exception. So if you can read and write from the variable, then everything is working correctly.
I tried "info tlb" inside QEMU, but I don't see any information printed.
The issue is no code appears to be able to write to the next_grab_slot variable. This needs to be fixed.
This patch should fix the division by zero issue. Only on the PowerPC platform will division by zero equal zero.
signed-off-by: John Arbuckle programmingkidx@gmail.com
Index: kernel/forth.c =================================================================== --- kernel/forth.c (revision 1080) +++ kernel/forth.c (working copy) @@ -1157,6 +1157,15 @@ { const ucell b = POP(); const ducell a = DPOP(); + +#if defined (CONFIG_PPC) || defined (CONFIG_PPC64) + if (b == 0) { // division by zero equals zero on PowerPC platform + PUSH(0); + DPUSH(0); + return; + } +#endif + #ifdef NEED_FAKE_INT128_T if (a.hi != 0) { fprintf(stderr, "mudivmod called (0x%016llx %016llx / 0x%016llx)\n",
In short, this is actually fine. You have to remember that OpenBIOS uses the MMU (emulated by QEMU) and hence physical pages can be mapped to any virtual address within the 32-bit address space of the PPC CPU.
Once the MMU is enabled in the OpenBIOS startup code, all addresses (including those used by gdb) are virtual addresses. If you want to view the current virtual to physical mappings, use the "info tlb" command from the QEMU monitor.
Note that if you try and access an unmapped address then you will normally obtain some kind of "page fault" or "TLB miss" processor exception. So if you can read and write from the variable, then everything is working correctly.
I tried the "info mtree" command and found out that the variable next_grab_slot's address is located in this section:
00000000fff00000-00000000ffffffff (prio 0, R-): ppc_heathrow.bios
next_grab_slots's address is 0xfffda060.
The "R-" seems to indicate that this section is read only explaining why the variable's value can't be changed. I am pretty sure static variables should not be kept in this region. How do we change where static and global variables are stored?
On 25/12/12 04:19, Programmingkid wrote:
I tried the "info mtree" command and found out that the variable next_grab_slot's address is located in this section:
00000000fff00000-00000000ffffffff (prio 0, R-): ppc_heathrow.bios
next_grab_slots's address is 0xfffda060.
The "R-" seems to indicate that this section is read only explaining why the variable's value can't be changed. I am pretty sure static variables should not be kept in this region. How do we change where static and global variables are stored?
Have you tried changing the value directly with gdb?
ATB,
Mark.
-
Mark Cave-Ayland -
Programmingkid