qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] S390 Status


From: Ulrich Hecht
Subject: Re: [Qemu-devel] S390 Status
Date: Mon, 21 Mar 2005 17:36:04 +0100
User-agent: KMail/1.8

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




reply via email to

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