I also get a SIGSEGV, but it occurs at

Program received signal SIGSEGV, Segmentation fault.
cpu_x86_exec (env1=0xf) at exec-all.h:225
225             if (!tb)
(gdb) info reg
r0             0x401d78c8       1075673288
r1             0xa022524c       -1608363444
r2             0xf      15
r3             0xfe092  1040530
r4             0xf0000  983040
r5             0x44     68
r6             0x7ffff138       2147479864
r7             0x6c866c 7112300
r8             0x0      0
r9             0x25784d6        39290070
r10            0x1316090        20013200
r11            0xfe092  1040530
r12            0x44     68
r13            0x80b0898e       -2135914098
r14            0x804511e4       -2142957084
r15            0x7ffff0d8       2147479768
pc             0x45116a 0x45116a <cpu_x86_exec+542>
cc             0x1      1
(gdb) disassemble $pc

[...]

0x0045116a <cpu_x86_exec+542>:  icm     %r2,15,0(%r1)


%r1 is not a valid address. Can anyone on this list shed some light on this ?


Ulrich Hecht wrote: 
Hi!

On Monday 21 March 2005 17:09, Jim Provan wrote:
  
Do you do your development on a real S390 or under Hercules ? The
reason that I ask is that I have an S390 available and would be
willing to put it on the net. I would give you all the time on it that
you need to be able to test out new patches for the S390. That would
go for any developers on this list as well that need S390 time.
    

We're well-equipped with Mainframe machinery, but I don't have enough of 
a clue to be able to fix the problem, although I have the feeling that 
it can't be that big. It seems memory is being overwritten:

(gdb) run
Starting program: /abuild/uli/qemu/arm-user/qemu-arm /tmp/ldconfig-arm
[Thread debugging using libthread_db enabled]
[New Thread 1075738304 (LWP 4173)]
program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075738304 (LWP 4173)]
cpu_arm_exec (env1=<value optimized out>) at exec-all.h:229
229             if (tb->pc == pc && tb->cs_base == cs_base && tb->flags 
== flags)
(gdb) info registers
r0             0x0      0
r1             0x0      0
r2             0xc00a0e1        201367777
r3             0xbf2c   48940
r4             0x1bbdc  113628
r5             0x0      0
r6             0xbf2c   48940
r7             0x600aed69       1611328873
r8             0x40267338       1076261688
r9             0x7ffff2f4       2147480308
r10            0x611320d8       1628643544
r11            0x7fffef18       2147479320
r12            0x0      0
r13            0xe092efdc       -527241252
r14            0xe00152d2       -536784174
r15            0x7fffeeb8       2147479224
pc             0x60015184       0x60015184 <cpu_arm_exec+500>
cc             0x2      2
(gdb) disassemble 0x60015184
[...]
0x60015184 <cpu_arm_exec+500>:  l       %r1,0(%r2)

So it apparently tries to read from address (%r2), which is 0x0c00a0e1, 
which is not a valid pointer, but looks very much like a little-endian 
ARM instruction to me. Unfortunately, my limited knowledge of 390 
assembler does not allow me to track this down any further.

CU
Uli


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel