In order to find out where certain QEMU functions are called from, using
test output is not practical.
Therefore I set out to use gdb to debug qemu-system-ppc64.exe (the
unstripped version):
gdb /cygdrive/c/MinGW/msys/1.0/local/qemu/qemu-system-ppc64
b pci_host_config_write_common
gdb responds with:
Breakpoint 1 at 0x6ecd79: file
C:/MinGW/msys/1.0/gnu_dev/qemu-2.5.0/hw/pci/pci_host.c, line 54.
Next I issue an r-command with the same options as I need to use:
r -m 240 -g 640x400x16 -name ppc -M ppce500 -cpu e5500 -bios u-boot.e500
-icount 2 -gdb tcp:127.0.0.1:1234,ipv4 -netdev tap,id=vlan0,ifname=tap0
-device virtio-net-pci,netdev=vlan0,id=virtio,bus=pci.0,addr=1.0, -kernel
Boot.bin -initrd Boot.qemu -device VGA -vga std
The gdb response here is:
[New Thread 9180.0x1c94]
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x6ecd54: Input/output error.
I then delete breakpoint 1 (del 1), and continue (c), and the program
starts running
gdb outputs
[New Thread 9180.0x12b8]
... (my test output lines) ...
[New Thread 9180.0x2234]
[New Thread 9180.0x233c]
...
and everything happens as usually, except I have not achieved the goal of
hitting any breakpoints.
Upon closer examination it appears that the qemu-system-ppc64.exe that is
linked to 0x400000 and up as any other Windows application, in fact has
been moved up higher in the address space a number of pages, but not
always the same number. I have seen 0xb600000 be the bias, and also
0x4c0000 and others. I found out by letting one of my test output lines
print the current EIP-value, as well as the (linked) address of the
function this happens inside. The 2 values were close to each other as
expected, and both were biased.
I must assume that the move of the qemu-system-ppc64.exe sections means
that this executable contains fixup relocations like what the objdump tool
reports:
/cygdrive/c/MinGW/msys/1.0/local/qemu/qemu-system-ppc64.exe: file
format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0086e6cc 00401000 00401000 00000600 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0007fbf4 00c70000 00c70000 0086ee00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 0027d17c 00cf0000 00cf0000 008eea00 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .eh_frame 000d8bd4 00f6e000 00f6e000 00b6bc00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .bss 004583c4 01047000 01047000 00000000 2**5
ALLOC
5 .edata 00001219 014a0000 014a0000 00c44800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .idata 0000311c 014a2000 014a2000 00c45c00 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .CRT 00000018 014a6000 014a6000 00c48e00 2**2
CONTENTS, ALLOC, LOAD, DATA
8 .tls 00000020 014a7000 014a7000 00c49000 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .rsrc 0000176c 014a8000 014a8000 00c49200 2**2
CONTENTS, ALLOC, LOAD, DATA
10 .reloc 00066440 014aa000 014aa000 00c4aa00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .debug_aranges 00005198 01511000 01511000 00cb1000 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_info 00bca2a4 01517000 01517000 00cb6200 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_abbrev 00078c18 020e2000 020e2000 01880600 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_line 001a8dce 0215b000 0215b000 018f9400 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_str 0005ceb2 02304000 02304000 01aa2200 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_loc 00098cb6 02361000 02361000 01aff200 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_ranges 0000d9e0 023fa000 023fa000 01b98000 2**0
CONTENTS, READONLY, DEBUGGING
I am using GNU gdb:
(GDB) 7.6.50.20130728-cvs (cygwin-special)
Is there a way to have this work?
Is it important that relocation takes place, or could it be fixed in the
virtual address space as its usual 0x400000 location?
I noticed the building of QEMU has -fPIC at least for compilation of at
least some files, but also --static.
Though I am only building this particular qemu-system-ppc64 variant, it
still takes me almost an hour to experiment with other compile and link
options.
Any help is highly appreciated!
Thorkil B. Rasmussen
