From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPpMZ-0003kx-Jo for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:59:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPpMS-0002nF-BT for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:59:23 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:52656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPpMR-0002mw-Rg for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:59:16 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NBF000AK7RCKQ60@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Fri, 05 Sep 2014 10:02:00 +0100 (BST) Message-id: <54097B5D.6010206@samsung.com> Date: Fri, 05 Sep 2014 12:59:09 +0400 From: Mikhail Ilin MIME-version: 1.0 References: <1407752887-6351-1-git-send-email-m.ilin@samsung.com> <53FB21C1.2020304@redhat.com> <53FB267A.2080903@redhat.com> In-reply-to: <53FB267A.2080903@redhat.com> Content-type: text/plain; charset=iso-8859-15; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, Riku Voipio , rth@twiddle.net, afaerber@suse.de, mst@redhat.com 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 >>> --- >>> 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 > >