[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] COMMIT e27b27b broke sparc32plus-linux-user
From: |
Reimar Döffinger |
Subject: |
Re: [Qemu-devel] COMMIT e27b27b broke sparc32plus-linux-user |
Date: |
Tue, 18 Aug 2009 17:40:15 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Tue, Aug 18, 2009 at 11:23:26AM -0400, Vince Weaver wrote:
> I'm not sure how this is possible, but somehow the commit
>
> [COMMIT e27b27b] Simplify 5ba6531956b9b6486560cbd13604c2238a3542dd
>
> broke sparc32plus-linux-user for me. All the binaries I try now segfault.
>
> A small binary that exhibits this can be found in the ll qemu test found
> here:
> http://www.deater.net/weave/vmwprod/asm/ll/qemu_tests.html
> but larger binaries also have issues.
>
> It is very strange, as I can't see how that particular commit should
> change anything sparc related.
Are you sure you didn't change your system, e.g. update your gcc?
I can reproduce it here, but I have been using gcc 4.4.1 and I have no
confidence it that gcc version.
Anyway, here is my backtrace:
#0 0x0000000000000000 in ?? ()
#1 0x000000006007bf92 in helper_compute_psr () at
/data/qemu/target-sparc/op_helper.c:1266
#2 0x00000000601e4ca6 in static_code_gen_buffer ()
#3 0x00000000622282c0 in ?? ()
#4 0x00007f5d0ec49010 in ?? ()
#5 0x00007fff4897790c in ?? ()
#6 0x000000006001dc82 in tb_link_phys (tb=0x10578, phys_pc=<value optimized
out>, phys_page2=66556) at /data/qemu/exec.c:1137
#7 0x000000006001e32c in tb_gen_code (env=0x7f5d0ec37010, pc=65620,
cs_base=<value optimized out>, flags=<value optimized out>, cflags=<value
optimized out>) at /data/qemu/exec.c:898
#8 0x000000006001f561 in cpu_sparc_exec (env1=<value optimized out>) at
/data/qemu/cpu-exec.c:652
#9 0x0000000060005758 in cpu_loop (env=0x7f5d0ec37010) at
/data/qemu/linux-user/main.c:888
#10 0x000000006000628b in main (argc=<value optimized out>,
argv=0x7fff4899c468, envp=<value optimized out>) at
/data/qemu/linux-user/main.c:3031
The problem is that in helper_compute_psr CC_OP is CC_OP_DYNAMIC, which
has no execution functions associated (and the code says it should never
happen).