I've also found that this issue in walker API leads to creating
a misformed core file. elf_core_dump() uses walk_memory_regions()
to build memory mapping for a core file.
As a result the core file has a very small size and doesn't contain
page snapshots of mapped libraries.
I've compiled a simple helloworld prog (which dereference a NULL
pointer at the end to get a core file) and run the prog twice
without a workaround patch and with it.
$ gcc -m32 -g -Wall -o /tmp/prog /tmp/prog.c
$ ulimic -c unlimited
I use i386 but the same works for ARM and believe for other 32bits
arches.
$ qemu-i386 /tmp/prog
Hello world!
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
Here is core files sizes without a workaround patch and with it.
$ ls -l
892 qemu_prog_20140905-121147_21636.core
8454144 qemu_prog_20140905-120737_21355.core
Also I've investigate them with gdb.
No workaround:
$ gdb /tmp/prog qemu_prog_20140905-121147_21636.core
Cannot access memory at address 0x407fffe4
#-1 0x08048406 in main () at /tmp/prog.c:8
Here is the fail because there is no mapping that contains address
0x407fffe4.
(gdb) info files
0x00048000 - 0x00048000 is load1
0x00049000 - 0x00049000 is load2
0x00040000 - 0x00040000 is load3
0x00041000 - 0x00041000 is load4
0x00041800 - 0x00041800 is load5
0x00061800 - 0x00061800 is load6
0x00062800 - 0x00062800 is load7
0x00045800 - 0x00045800 is load8
0x001ee800 - 0x001ee800 is load9
0x001ef800 - 0x001ef800 is load10
0x001f1800 - 0x001f1800 is load11
....
With workaround:
0x08048000 - 0x08048000 is load1
0x08049000 - 0x0804a000 is load2
0x40000000 - 0x40000000 is load3
0x40001000 - 0x40801000 is load4
0x40801000 - 0x40801000 is load5
0x40821000 - 0x40822000 is load6
0x40822000 - 0x40827000 is load7
0x40845000 - 0x40845000 is load8
0x409ee000 - 0x409ee000 is load9
0x409ef000 - 0x409f1000 is load10
0x409f1000 - 0x409f7000 is load11
address 0x407fffe4 belongs to load4.
Also this core includes other library mappings that are not
presented in the core file without a workaround:
0x40845174 - 0x40845198 is /lib/i386-linux-gnu/libc.so.6
0x40845198 - 0x408451b8 is /lib/i386-linux-gnu/libc.so.6
0x408451b8 - 0x40848ec8 is /lib/i386-linux-gnu/libc.so.6
0x40848ec8 - 0x40852438 is /lib/i386-linux-gnu/libc.so.6
0x40852438 - 0x4085815e is /lib/i386-linux-gnu/libc.so.6
0x4085815e - 0x4085940c is /lib/i386-linux-gnu/libc.so.6
0x4085940c - 0x40859898 is /lib/i386-linux-gnu/libc.so.6
0x40859898 - 0x408598d8 is /lib/i386-linux-gnu/libc.so.6
0x408598d8 - 0x4085c2e8 is /lib/i386-linux-gnu/libc.so.6
0x4085c2e8 - 0x4085c348 is /lib/i386-linux-gnu/libc.so.6
0x4085c350 - 0x4085c420 is /lib/i386-linux-gnu/libc.so.6
0x4085c420 - 0x4098e44e is /lib/i386-linux-gnu/libc.so.6
0x4098e450 - 0x4098f3db is /lib/i386-linux-gnu/libc.so.6
0x4098f3e0 - 0x4098f5de is /lib/i386-linux-gnu/libc.so.6
> This patch fails to compile for MIPS N32 (a 32-bit ABI with a 64-bit
> virtual address space).
I also wonder we have separate linux-user emulators for i386 (32 bit
ABI + 32 bit address space) and amd64 binaries (64 bit ABI + 64 bit
address space). And we can not run 32 bits apps under qemu-x86_64 but
MIPS N32 looks in some other way and it supports 32 bit ABI apps with
64 bit address space. I really not sure but is it a right design or
not?
> Riku, do you have any ideas (or free cycles to do the change)?
Please, give some clues.
Thanks.
On 25.08.2014 16:05, Paolo Bonzini wrote:
Il 25/08/2014 13:45, Paolo Bonzini ha scritto:
Il 11/08/2014 12:28, Mikhail Ilyin ha scritto:
Fix memory maps textualizing function. The output was not correct because of
wrong base address calculation. The initial address has to be shifted also
for TARGET_PAGE_BITS.
Signed-off-by: Mikhail Ilyin <m.i...@samsung.com>
---
translate-all.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/translate-all.c b/translate-all.c
index 8f7e11b..cb7a33d 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -1728,9 +1728,8 @@ int walk_memory_regions(void *priv,
walk_memory_regions_fn fn)
data.prot = 0;
for (i = 0; i < V_L1_SIZE; i++) {
- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
+ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT +
TARGET_PAGE_BITS),
V_L1_SHIFT / V_L2_BITS - 1, l1_map +
i);
-
if (rc != 0) {
return rc;
}
Thanks, this is simple enough that I've queued it.
Ouch, I spoke too soon.
This patch fails to compile for MIPS N32 (a 32-bit ABI with a 64-bit
virtual address space). I'm not sure if there is a simple fix.
walk_memory_regions and its user should be changed to use target_ulong
instead of abi_ulong. access_ok probably needs to be changed in the
same way too. Riku, do you have any ideas (or free cycles to do the
change)?
Paolo
