On 08/04/2016 13:50, trasmus...@ddci.com wrote:
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:
Actually, you are seeing that the Windows version you
use supports ASLR (Address Space Layout Randomization)
to reduce the risk that buffer overflow vulnerabilities
can be effectively exploited.
If gdb fails to adjust correctly to the resulting
relocation of the program, this would be a serious
gdb bug, given that ASLR is also implemented (though
differently) on Linux based systems.
It is possible (as you suggest yourself) to disable
ASLR for a windows exe by either:
A) Stripping away the relocations so the exe can only
be loaded at the default address specified in the
PE header.
B) Clearing/Setting one of the EXE feature flags (the
one named "/DYNAMICBASE:NO" in Microsoft tools) in
the PE header.
Of cause, doing this is enough of a security
disadvantage that Microsoft is releasing critical
security patches for any Microsoft program that has
been released with ASLR disabled, so it should only
be done while debugging.
/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
Note that the above output also indicates that the used
version of objdump seems to parse COFF section descriptors
incorrectly. Each descriptor contains the following
size/offset related numbers:
- Location in memory after loading (shown TWICE in the above output)
- Location in file before loading (shown)
- Size in memory after loading (this or the next one not shown above)
- Size in file before loading (this or the previous one not shown above)
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
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded