Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing

[Mikhail Ilin]

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 <address@hidden>
> > > ---
> > >   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