|
| From: | Stefan Weil |
| Subject: | Re: [Qemu-devel] Fwd: Re: [target-mips] qemu on centos |
| Date: | Fri, 23 Dec 2011 23:57:51 +0100 |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Iceowl/1.0b1 Icedove/3.0.11 |
Am 23.12.2011 19:05, schrieb Brendan Kirby:
Attached are three MIPS binaries that I have seen segfault intermittently on CentOS 6 machines. Just run them with no arguments several times. Brendan On Fri, 2011-12-23 at 09:00 -0800, Reed Kotler wrote:Please work with this guy. If possible, submit some test cases to them of some code that causes segfaults on Centos 6, even if intermittent. Reed -------- Original Message -------- Subject: Re: [Qemu-devel] [target-mips] qemu on centos Date: Fri, 23 Dec 2011 14:25:57 +0100 From: Andreas Färber <address@hidden> Organization: SUSE LINUX Products GmbH To: Reed Kotler <address@hidden> CC: <address@hidden>, Khansa Butt <address@hidden>, Richard Henderson <address@hidden>, Richard Sandiford <address@hidden> Hi, Am 23.12.2011 13:44, schrieb Reed Kotler:We have been seeing various problems running qemu for MIPS target on Centos 5. We are running linux user mode programs. Qemu segfaults. We recently tried upgrading to Centos 6 and the problem there is much worse, making it basically unusable. The same programs have no problem when running on Ubuntu.They likely are using different QEMU versions, and distros may have different patches applied on top. Please provide some more info on what version, what ABI (which executable), what -cpu parameter (if any), etc. you are using. Does a gdb backtrace indicate any QEMU function or is it from translated code? For n64 there were some patches in need of testing, review and fixing. [cc'ing Khansa] For n32 there's signal handling missing. (openSUSE for one ignores the build warning and provides it non the less.) No known issues specific to o32 that I'm aware of, but the two Richards had patches for some instructions. Shouldn't lead to segfaults though. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Please add your message at the bottom of the mail, not at the top. I tried your binaries with latest QEMU. All three fail here each time with SIGSEGV. This is caused by a jump to address 0 (pc = 0). Up to now I don't know the reason for this jump. Call stack:#0 0x00005555555f62d2 in ldl_le_p (ptr=0x0) at /home/stefan/src/qemu/qemu.org/qemu/bswap.h:477 #1 0x000055555561333e in gen_intermediate_code_internal (env=0x555557ca0b10, tb=0x7ffff3982108, search_pc=0) at /home/stefan/src/qemu/qemu.org/qemu/target-mips/translate.c:12442 #2 0x0000555555613709 in gen_intermediate_code (env=0x555557ca0b10, tb=0x7ffff3982108) at /home/stefan/src/qemu/qemu.org/qemu/target-mips/translate.c:12528 #3 0x00005555555f5f8d in cpu_mips_gen_code (env=0x555557ca0b10, tb=0x7ffff3982108, gen_code_size_ptr=0x7fffffffd748) at /home/stefan/src/qemu/qemu.org/qemu/translate-all.c:66 #4 0x00005555555a33b3 in tb_gen_code (env=0x555557ca0b10, pc=0, cs_base=0, flags=34, cflags=0) at /home/stefan/src/qemu/qemu.org/qemu/exec.c:1003 #5 0x000055555559c5b2 in tb_find_slow (env=0x555557ca0b10, pc=0, cs_base=0, flags=34) at /home/stefan/src/qemu/qemu.org/qemu/cpu-exec.c:126 #6 0x000055555559c73c in tb_find_fast (env=0x555557ca0b10) at /home/stefan/src/qemu/qemu.org/qemu/cpu-exec.c:153 #7 0x000055555559cb2a in cpu_mips_exec (env=0x555557ca0b10) at /home/stefan/src/qemu/qemu.org/qemu/cpu-exec.c:536 #8 0x00005555555bf780 in cpu_loop (env=0x555557ca0b10) at /home/stefan/src/qemu/qemu.org/qemu/linux-user/main.c:2160 #9 0x00005555555c16ac in main (argc=7, argv=0x7fffffffe1c8, envp=0x7fffffffe208) at /home/stefan/src/qemu/qemu.org/qemu/linux-user/main.c:3812
Try running a working version and the bad version with
mipsel-linux-user/qemu-mipsel -d in_asm,cpu -singlestep ...
and compare the resulting output file /tmp/qemu.log.
For programs without external events (timers and other
interrupt sources), the program flow should be identical
(same instructions, same register values).
This should identify the mips code which is handled differently
by the two versions.
Here is an extract of my qemu.log which shows the jump to
address 0.
pc=0x004027d8 HI=0x0000018a LO=0x0000f816 ds 0022 004027c0 0
GPR00: r0 00000000 at fffffff8 v0 4081190c v1 00000814
GPR04: a0 0040248c a1 00000001 a2 4080042c a3 00402650
GPR08: t0 004026f4 t1 0ffffffe t2 00000063 t3 00000002
GPR12: t4 40800180 t5 40800228 t6 ffffffff t7 00400538
GPR16: s0 4083a010 s1 004004f0 s2 00000000 s3 00000000
GPR20: s4 00000000 s5 00000000 s6 00000000 s7 00000000
GPR24: t8 00000002 t9 00000000 k0 00000000 k1 00000000
GPR28: gp 00412804 sp 40800408 s8 00000000 ra 00400538
CP0 Status 0x00000000 Cause 0x00000000 EPC 0x00000000
Config0 0x80000482 Config1 0x9e190c8f LLAddr 0xffffffff
CP1 FCR0 0x00000000 FCR31 0x00000000 SR.FR 0 fp_status 0x00
f0: w:3f800000 d:400000003f800000 fd: 4.61169e+18 fs: 1.06535e+09
psu: 1.07374e+09
f2: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f4: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f6: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f8: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f10: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f12: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f14: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f16: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f18: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f20: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f22: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f24: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f26: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f28: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
f30: w:00000000 d:0000000000000000 fd: 0 fs: 0
psu: 0
IN: 0x004027d8: jalr t9 An older qemu-mipsel from August fails, too. Regards, Stefan Weil
| [Prev in Thread] | Current Thread | [Next in Thread] |