[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM Memory

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion
Date: Thu, 01 Dec 2011 11:24:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 11/30/2011 06:22 PM, Andreas Färber wrote:
> The problem is not with the 0xfff00 region, that one works fine with 12
> and 16 bit pages so far.
> What I'm seeing is a crash of the very first TB at PC 0x02010, which is
> in a 4K RAM region from 0x0 on, with 16 bit pages. Also happens with v2.

Executing out of subpage RAM is probably unique enough to have its own
set of weird and wonderful bugs.

Since it's the very first TB, you could simply add tons of
instrumentation and just follow the guest code and see what it does.

> It's similar to my original problem of being unable to read the reset
> vector, where I couldn't use the regular memory read functions but had
> to use rom_ptr(), as Peter pointed out in
> target-arm/helper.c:cpu_reset(). Apparently I'll need to add some check
> for handling ROM, but on what condition and where? Don't really
> understand why loading ELF code into a RAM area creates these weird ROM
> areas... Is this a legacy thing, as it's not shown in info mtree?

Everything should be seen in 'info mtree', at least for everything
that's been converted.  You could try the memory/master branch where
this is true.  Did you add roms yourself?

> (qemu) info roms
> addr=00000000 size=0x000002 mem=rom name="phdr #0:
> /home/andreas/MCU/RL78/test"
> addr=00000004 size=0x00007c mem=rom name="phdr #1:
> /home/andreas/MCU/RL78/test"
> addr=000000c0 size=0x000004 mem=rom name="phdr #2:
> /home/andreas/MCU/RL78/test"
> addr=000000d8 size=0x000004 mem=rom name="phdr #3:
> /home/andreas/MCU/RL78/test"
> addr=000000dc size=0x00026a mem=rom name="phdr #4:
> /home/andreas/MCU/RL78/test"
> addr=00002000 size=0x0004e4 mem=rom name="phdr #5:
> /home/andreas/MCU/RL78/test"
> (qemu) cont
> Bad ram pointer 0x2010
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7ffff5504700 (LWP 6484)]
> 0x00007ffff617ad95 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff617ad95 in raise () from /lib64/libc.so.6
> #1  0x00007ffff617c2ab in abort () from /lib64/libc.so.6
> #2  0x00007ffff7f76928 in qemu_ram_addr_from_host_nofail (ptr=0x2010)
>     at /home/andreas/QEMU/qemu-rl78/exec.c:3248
> #3  qemu_ram_addr_from_host_nofail (ptr=0x2010)
>     at /home/andreas/QEMU/qemu-rl78/exec.c:3242
> #4  0x00007ffff7f7036d in get_page_addr_code (addr=8208,
> env1=0x7ffff8b04010)

This function tries to translate a virtual guest address of a page into
a ram address, but that doesn't work for subpage.

    if (pd > IO_MEM_ROM && !(pd & IO_MEM_ROMD)) {
#if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SPARC)
        cpu_unassigned_access(env1, addr, 0, 1, 0, 4);
        cpu_abort(env1, "Trying to execute code outside RAM or ROM at
0x" TARGET_FMT_lx "\n", addr);

You're clearly in RAM or ROM, but the subpage code confuses qemu.  It's
not going to be easy to unconfuse it.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]