qemu-devel
[Top][All Lists]
Advanced

[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).




reply via email to

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