[Qemu-devel] ARM

[Qemu-devel] ARM

[Daniel Jacobowitz]

I was just playing with the ARM support, it's great to see it taking
shape :)  Fabrice, are you still investigating it, or does it work for
you?  My local ARM setup crashes a few hundred instructions into ld.so;
a loop runs for too long and hits the top of the stack.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [Qemu-devel] ARM

[Fabrice Bellard]

Daniel Jacobowitz wrote:
> I was just playing with the ARM support, it's great to see it taking
> shape :)  Fabrice, are you still investigating it, or does it work for
> you?  My local ARM setup crashes a few hundred instructions into ld.so;
> a loop runs for too long and hits the top of the stack.
> 

With my latest commits it is working: QEMU can launch dynamically linked 
'ls' and 'bash' processes. I will provide soon a binary archive so that 
people can at least try it if they have problems.

Warning: no FPU emulation is done. I just added the necessary code to 
skip the few FPU instructions present in the libc. If anyone has ideas 
about FPU on ARM, I am interested. Unfortunately the Linux distributions 
seem to use the kernel based NetWinder FPU emulator.

I tested the ARM support with an ARM glibc-2.2.5 from a debian 3.0 
installed on a StrongARM board.

Fabrice.

Re: [Qemu-devel] ARM

[Jocelyn Mayer]

On Wed, 2003-07-09 at 20:35, Daniel Jacobowitz wrote:
> I was just playing with the ARM support, it's great to see it taking
> shape :)  Fabrice, are you still investigating it, or does it work for
> you?  My local ARM setup crashes a few hundred instructions into ld.so;
> a loop runs for too long and hits the top of the stack.

Hello,

Maybe a flag problem..
As I was looking the overflow flag calculation, while trying to fix it
in my PPC emulation, I noticed that this flag should be masked with (1
<< 31) to be correct.
Fabrice, could you confirm this point ?
It seems to work well in my PPC code...

It may also comes from the fact that the qemu Elf loader builds a
"buggy" stack. I don't known anything about the ABI for the ARM, but I
noticed that the stack wasn't aligned properly on PPC and that some
informations were missing, but I don't really know if those infos are
vital or not. 
Even in x86 emulation, the stack is really different from the one built
by the Linux kernel (I compared with a linux-2.4.21 kernel).
I fixed some crashes, changing this code to do the same as the kernel,
but dynamic x86 loading is now buggy with that patch...

Regards.

-- 
Jocelyn Mayer <jma@netgem.com>

Re: [Qemu-devel] ARM

[Fabrice Bellard]

Jocelyn Mayer wrote:
 > On Wed, 2003-07-09 at 20:35, Daniel Jacobowitz wrote:
 >
 >> I was just playing with the ARM support, it's great to see it
 >> taking shape :)  Fabrice, are you still investigating it, or does
 >> it work for you?  My local ARM setup crashes a few hundred
 >> instructions into ld.so; a loop runs for too long and hits the top
 >> of the stack.
 >
 >
 > Hello,
 >
 > Maybe a flag problem.. As I was looking the overflow flag
 > calculation, while trying to fix it in my PPC emulation, I noticed
 > that this flag should be masked with (1 << 31) to be correct. Fabrice,
 > could you confirm this point ?

Yes, the overflow flag should be masked with (1 << 31). For ARM, the
masking does not need to be done as the overflow is computed in a
separate variable.

 > It seems to work well in my PPC code...
 >
 > It may also comes from the fact that the qemu Elf loader builds a "buggy"
 > stack. I don't known anything about the ABI for the ARM, but I noticed
 > that the stack wasn't aligned properly on PPC and that some informations
 > were missing, but I don't really know if those infos are vital or
 > not. Even in x86 emulation, the stack is really different from the
 > one built by the Linux kernel (I compared with a linux-2.4.21
 > kernel). I fixed some crashes, changing this code to do the same as
 > the kernel, but dynamic x86 loading is now buggy with that patch...

Yes, alignment is not done properly yet as the elf loader comes from a 
very old Linux kernel. If you except the alignment bug, none of the 
differences should be critical.

Fabrice.

Re: [Qemu-devel] ARM

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Wed, Jul 09, 2003 at 09:49:33PM +0200, Fabrice Bellard wrote:
> Daniel Jacobowitz wrote:
> >I was just playing with the ARM support, it's great to see it taking
> >shape :)  Fabrice, are you still investigating it, or does it work for
> >you?  My local ARM setup crashes a few hundred instructions into ld.so;
> >a loop runs for too long and hits the top of the stack.
> >
> 
> With my latest commits it is working: QEMU can launch dynamically linked 
> 'ls' and 'bash' processes. I will provide soon a binary archive so that 
> people can at least try it if they have problems.

Still doesn't work here.  I've attached the debugging output if you're
curious; I won't have time to debug it properly until next week.  It
looks like something wrong with the conditional jump.

> Warning: no FPU emulation is done. I just added the necessary code to 
> skip the few FPU instructions present in the libc. If anyone has ideas 
> about FPU on ARM, I am interested. Unfortunately the Linux distributions 
> seem to use the kernel based NetWinder FPU emulator.

Yes; here we use userspace software floating point generally instead. 
Hardware which actually has the FPA unit is rare (is there any
supported?)

> I tested the ARM support with an ARM glibc-2.2.5 from a debian 3.0 
> installed on a StrongARM board.

My failing test is from a later version of glibc and GCC.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[-- Attachment #2: qemu.log --]
[-- Type: text/plain, Size: 8062 bytes --]

start    end      size     prot
00008000-00019000 00011000 r-x
00020000-00021000 00001000 rw-
40158000-401d8000 00080000 rw-
401d8000-401d9000 00001000 ---
401d9000-401ef000 00016000 r-x
401ef000-401f6000 00007000 ---
401f6000-401f7000 00001000 rw-
401f7000-401f8000 00001000 rwx
401f8000-421d9000 01fe1000 ---
start_brk   0x00020b0c
end_code    0x00018240
start_code  0x00008000
end_data    0x00020b0c
start_stack 0x401d7604
brk         0x00020b0c
entry       0x401dad10
----------------
IN: 
0x401dad10:  mov	r0, sp
0x401dad14:  bl	0x401daeac

OP:
0x0000: movl_T1_r13
0x0001: movl_r0_T1
0x0002: movl_T0_im 0x401dad18
0x0003: movl_r14_T0
0x0004: jmp 0x800764a0 0x401daeac
0x0005: end

OUT: [size=35]
0x802364a0:  movl   0x34(%ebp),%esi
0x802364a3:  movl   %esi,0x0(%ebp)
0x802364a6:  movl   $0x401dad18,%ebx
0x802364ab:  movl   %ebx,0x38(%ebp)
0x802364ae:  jmp    *0x800764c8
0x802364b4:  movl   %esi,%esi
0x802364b6:  movl   $0x800764a1,%ebx
0x802364bb:  movl   $0x401daeac,0x3c(%ebp)
0x802364c2:  ret    

----------------
IN: 
0x401daeac:  stmdb	sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0x401daeb0:  ldr	r10, [pc, #1584]	; 0x401db4e8
0x401daeb4:  sub	sp, sp, #464	; 0x1d0
0x401daeb8:  mov	r2, #0	; 0x0
0x401daebc:  str	r0, [sp, #12]
0x401daec0:  add	r10, pc, r10
0x401daec4:  mov	r1, r2
0x401daec8:  add	r3, sp, #464	; 0x1d0
0x401daecc:  add	r2, r2, #1	; 0x1
0x401daed0:  cmp	r2, #52	; 0x34
0x401daed4:  str	r1, [r3, -#400]
0x401daed8:  add	r3, r3, #4	; 0x4
0x401daedc:  bls	0x401daecc

OP:
0x0000: movl_T1_r13
0x0001: addl_T1_im 0xffffffdc
0x0002: movl_T0_r4
0x0003: stl_T0_T1
0x0004: addl_T1_im 0x4
0x0005: movl_T0_r5
0x0006: stl_T0_T1
0x0007: addl_T1_im 0x4
0x0008: movl_T0_r6
0x0009: stl_T0_T1
0x000a: addl_T1_im 0x4
0x000b: movl_T0_r7
0x000c: stl_T0_T1
0x000d: addl_T1_im 0x4
0x000e: movl_T0_r8
0x000f: stl_T0_T1
0x0010: addl_T1_im 0x4
0x0011: movl_T0_r9
0x0012: stl_T0_T1
0x0013: addl_T1_im 0x4
0x0014: movl_T0_r10
0x0015: stl_T0_T1
0x0016: addl_T1_im 0x4
0x0017: movl_T0_r11
0x0018: stl_T0_T1
0x0019: addl_T1_im 0x4
0x001a: movl_T0_r14
0x001b: stl_T0_T1
0x001c: addl_T1_im 0xffffffe0
0x001d: movl_r13_T1
0x001e: movl_T1_im 0x401daeb8
0x001f: addl_T1_im 0x630
0x0020: ldl_T0_T1
0x0021: movl_r10_T0
0x0022: movl_T1_im 0x1d0
0x0023: movl_T0_r13
0x0024: subl_T0_T1
0x0025: movl_r13_T0
0x0026: movl_T1_im 0x0
0x0027: movl_r2_T1
0x0028: movl_T1_r13
0x0029: addl_T1_im 0xc
0x002a: movl_T0_r0
0x002b: stl_T0_T1
0x002c: movl_T1_r10
0x002d: movl_T0_im 0x401daec8
0x002e: addl_T0_T1
0x002f: movl_r10_T0
0x0030: movl_T1_r2
0x0031: movl_r1_T1
0x0032: movl_T1_im 0x1d0
0x0033: movl_T0_r13
0x0034: addl_T0_T1
0x0035: movl_r3_T0
0x0036: movl_T1_im 0x1
0x0037: movl_T0_r2
0x0038: addl_T0_T1
0x0039: movl_r2_T0
0x003a: movl_T1_im 0x34
0x003b: movl_T0_r2
0x003c: subl_T0_T1_cc
0x003d: movl_T1_r3
0x003e: addl_T1_im 0xfffffe70
0x003f: movl_T0_r1
0x0040: stl_T0_T1
0x0041: movl_T1_im 0x4
0x0042: movl_T0_r3
0x0043: addl_T0_T1
0x0044: movl_r3_T0
0x0045: test_hi 0x800764d8 0x401daee0
0x0046: jmp 0x800764d8 0x401daecc
0x0047: end

OUT: [size=323]
0x802364d0:  movl   0x34(%ebp),%esi
0x802364d3:  addl   $0xffffffdc,%esi
0x802364d9:  movl   0x10(%ebp),%ebx
0x802364dc:  movl   %ebx,(%esi)
0x802364de:  addl   $0x4,%esi
0x802364e4:  movl   0x14(%ebp),%ebx
0x802364e7:  movl   %ebx,(%esi)
0x802364e9:  addl   $0x4,%esi
0x802364ef:  movl   0x18(%ebp),%ebx
0x802364f2:  movl   %ebx,(%esi)
0x802364f4:  addl   $0x4,%esi
0x802364fa:  movl   0x1c(%ebp),%ebx
0x802364fd:  movl   %ebx,(%esi)
0x802364ff:  addl   $0x4,%esi
0x80236505:  movl   0x20(%ebp),%ebx
0x80236508:  movl   %ebx,(%esi)
0x8023650a:  addl   $0x4,%esi
0x80236510:  movl   0x24(%ebp),%ebx
0x80236513:  movl   %ebx,(%esi)
0x80236515:  addl   $0x4,%esi
0x8023651b:  movl   0x28(%ebp),%ebx
0x8023651e:  movl   %ebx,(%esi)
0x80236520:  addl   $0x4,%esi
0x80236526:  movl   0x2c(%ebp),%ebx
0x80236529:  movl   %ebx,(%esi)
0x8023652b:  addl   $0x4,%esi
0x80236531:  movl   0x38(%ebp),%ebx
0x80236534:  movl   %ebx,(%esi)
0x80236536:  addl   $0xffffffe0,%esi
0x8023653c:  movl   %esi,0x34(%ebp)
0x8023653f:  movl   $0x401daeb8,%esi
0x80236544:  addl   $0x630,%esi
0x8023654a:  movl   (%esi),%ebx
0x8023654c:  movl   %ebx,0x28(%ebp)
0x8023654f:  movl   $0x1d0,%esi
0x80236554:  movl   0x34(%ebp),%ebx
0x80236557:  subl   %esi,%ebx
0x80236559:  movl   %ebx,0x34(%ebp)
0x8023655c:  movl   $0x0,%esi
0x80236561:  movl   %esi,0x8(%ebp)
0x80236564:  movl   0x34(%ebp),%esi
0x80236567:  addl   $0xc,%esi
0x8023656d:  movl   0x0(%ebp),%ebx
0x80236570:  movl   %ebx,(%esi)
0x80236572:  movl   0x28(%ebp),%esi
0x80236575:  movl   $0x401daec8,%ebx
0x8023657a:  addl   %esi,%ebx
0x8023657c:  movl   %ebx,0x28(%ebp)
0x8023657f:  movl   0x8(%ebp),%esi
0x80236582:  movl   %esi,0x4(%ebp)
0x80236585:  movl   $0x1d0,%esi
0x8023658a:  movl   0x34(%ebp),%ebx
0x8023658d:  addl   %esi,%ebx
0x8023658f:  movl   %ebx,0xc(%ebp)
0x80236592:  movl   $0x1,%esi
0x80236597:  movl   0x8(%ebp),%ebx
0x8023659a:  addl   %esi,%ebx
0x8023659c:  movl   %ebx,0x8(%ebp)
0x8023659f:  movl   $0x34,%esi
0x802365a4:  movl   0x8(%ebp),%ebx
0x802365a7:  movl   %ebx,%eax
0x802365a9:  xorl   %edx,%edx
0x802365ab:  subl   %esi,%ebx
0x802365ad:  cmpl   %esi,%eax
0x802365af:  setae  %dl
0x802365b2:  movl   %edx,0x44(%ebp)
0x802365b5:  movl   %eax,%edx
0x802365b7:  xorl   %esi,%edx
0x802365b9:  xorl   %ebx,%eax
0x802365bb:  andl   %edx,%eax
0x802365bd:  movl   %ebx,0x4c(%ebp)
0x802365c0:  movl   %eax,0x48(%ebp)
0x802365c3:  movl   0xc(%ebp),%esi
0x802365c6:  addl   $0xfffffe70,%esi
0x802365cc:  movl   0x4(%ebp),%ebx
0x802365cf:  movl   %ebx,(%esi)
0x802365d1:  movl   $0x4,%esi
0x802365d6:  movl   0xc(%ebp),%ebx
0x802365d9:  addl   %esi,%ebx
0x802365db:  movl   %ebx,0xc(%ebp)
0x802365de:  movl   0x44(%ebp),%eax
0x802365e1:  testl  %eax,%eax
0x802365e3:  je     0x802365fe
0x802365e5:  movl   0x4c(%ebp),%eax
0x802365e8:  testl  %eax,%eax
0x802365ea:  je     0x802365fe
0x802365ec:  jmp    *0x800764fc
0x802365f2:  movl   $0x800764d8,%ebx
0x802365f7:  movl   $0x401daee0,0x3c(%ebp)
0x802365fe:  jmp    *0x80076500
0x80236604:  movl   %esi,%esi
0x80236606:  movl   $0x800764d9,%ebx
0x8023660b:  movl   $0x401daecc,0x3c(%ebp)
0x80236612:  ret    

----------------
IN: 
0x401daecc:  add	r2, r2, #1	; 0x1
0x401daed0:  cmp	r2, #52	; 0x34
0x401daed4:  str	r1, [r3, -#400]
0x401daed8:  add	r3, r3, #4	; 0x4
0x401daedc:  bls	0x401daecc

OP:
0x0000: movl_T1_im 0x1
0x0001: movl_T0_r2
0x0002: addl_T0_T1
0x0003: movl_r2_T0
0x0004: movl_T1_im 0x34
0x0005: movl_T0_r2
0x0006: subl_T0_T1_cc
0x0007: movl_T1_r3
0x0008: addl_T1_im 0xfffffe70
0x0009: movl_T0_r1
0x000a: stl_T0_T1
0x000b: movl_T1_im 0x4
0x000c: movl_T0_r3
0x000d: addl_T0_T1
0x000e: movl_r3_T0
0x000f: test_hi 0x80076510 0x401daee0
0x0010: jmp 0x80076510 0x401daecc
0x0011: end

OUT: [size=129]
0x80236620:  movl   $0x1,%esi
0x80236625:  movl   0x8(%ebp),%ebx
0x80236628:  addl   %esi,%ebx
0x8023662a:  movl   %ebx,0x8(%ebp)
0x8023662d:  movl   $0x34,%esi
0x80236632:  movl   0x8(%ebp),%ebx
0x80236635:  movl   %ebx,%eax
0x80236637:  xorl   %edx,%edx
0x80236639:  subl   %esi,%ebx
0x8023663b:  cmpl   %esi,%eax
0x8023663d:  setae  %dl
0x80236640:  movl   %edx,0x44(%ebp)
0x80236643:  movl   %eax,%edx
0x80236645:  xorl   %esi,%edx
0x80236647:  xorl   %ebx,%eax
0x80236649:  andl   %edx,%eax
0x8023664b:  movl   %ebx,0x4c(%ebp)
0x8023664e:  movl   %eax,0x48(%ebp)
0x80236651:  movl   0xc(%ebp),%esi
0x80236654:  addl   $0xfffffe70,%esi
0x8023665a:  movl   0x4(%ebp),%ebx
0x8023665d:  movl   %ebx,(%esi)
0x8023665f:  movl   $0x4,%esi
0x80236664:  movl   0xc(%ebp),%ebx
0x80236667:  addl   %esi,%ebx
0x80236669:  movl   %ebx,0xc(%ebp)
0x8023666c:  movl   0x44(%ebp),%eax
0x8023666f:  testl  %eax,%eax
0x80236671:  je     0x8023668c
0x80236673:  movl   0x4c(%ebp),%eax
0x80236676:  testl  %eax,%eax
0x80236678:  je     0x8023668c
0x8023667a:  jmp    *0x80076534
0x80236680:  movl   $0x80076510,%ebx
0x80236685:  movl   $0x401daee0,0x3c(%ebp)
0x8023668c:  jmp    *0x80076538
0x80236692:  movl   %esi,%esi
0x80236694:  movl   $0x80076511,%ebx
0x80236699:  movl   $0x401daecc,0x3c(%ebp)
0x802366a0:  ret    

Re: [Qemu-devel] ARM

[Laurent Desnogues]

> Warning: no FPU emulation is done. I just added the necessary code to 
> skip the few FPU instructions present in the libc. If anyone has ideas 
> about FPU on ARM, I am interested

   When I wrote my ARM v5TE simulator, ARM ISA documentation only
talked about the VFP unit which had no silicon implementation...
It looks like there are multiple other FP units on ARM, kind of
messy!  So what specific implementation is required for QEMU?


        Laurent

Re: [Qemu-devel] ARM

[Fabrice Bellard]

which version of x86 gcc do you use ? It seems to be a problem with x86 
coge generator. Did you take my latest commit in exec.h ? The 'return' I 
added in it does not seem to be generated in the x86 code.

Fabrice.

Daniel Jacobowitz wrote:
> On Wed, Jul 09, 2003 at 09:49:33PM +0200, Fabrice Bellard wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>>I was just playing with the ARM support, it's great to see it taking
>>>shape :)  Fabrice, are you still investigating it, or does it work for
>>>you?  My local ARM setup crashes a few hundred instructions into ld.so;
>>>a loop runs for too long and hits the top of the stack.
>>>
>>
>>With my latest commits it is working: QEMU can launch dynamically linked 
>>'ls' and 'bash' processes. I will provide soon a binary archive so that 
>>people can at least try it if they have problems.
> 
> 
> Still doesn't work here.  I've attached the debugging output if you're
> curious; I won't have time to debug it properly until next week.  It
> looks like something wrong with the conditional jump.
> 
> 
>>Warning: no FPU emulation is done. I just added the necessary code to 
>>skip the few FPU instructions present in the libc. If anyone has ideas 
>>about FPU on ARM, I am interested. Unfortunately the Linux distributions 
>>seem to use the kernel based NetWinder FPU emulator.
> 
> 
> Yes; here we use userspace software floating point generally instead. 
> Hardware which actually has the FPA unit is rare (is there any
> supported?)
> 
> 
>>I tested the ARM support with an ARM glibc-2.2.5 from a debian 3.0 
>>installed on a StrongARM board.
> 
> 
> My failing test is from a later version of glibc and GCC.

Re: [Qemu-devel] ARM

[Daniel Jacobowitz]

On Thu, Jul 10, 2003 at 06:45:03PM +0200, Laurent Desnogues wrote:
> > Warning: no FPU emulation is done. I just added the necessary code to 
> > skip the few FPU instructions present in the libc. If anyone has ideas 
> > about FPU on ARM, I am interested
> 
>    When I wrote my ARM v5TE simulator, ARM ISA documentation only
> talked about the VFP unit which had no silicon implementation...
> It looks like there are multiple other FP units on ARM, kind of
> messy!  So what specific implementation is required for QEMU?

The Linux/ARM ABI specifies the use of FPA byte-ordering for floats. 
But I wouldn't shed any tears if QEmu didn't bother to implement the
relevant coprocessor.  FPA's really annoying; the byte ordering is
big-byte-little-word (or the other way around).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [Qemu-devel] ARM

[Daniel Jacobowitz]

Aha - the Makefile doesn't have accurate dependencies.  If I clean out
and rebuild qemu, the results are much better.  I get this:

open("/big/src/qemu/o/lib/librt.so.1", O_RDONLY) = 3
mprotect(0x401d6000, 4096, PROT_READ|PROT_WRITE) = 0
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\244\33\0"..., 1024) = 1024
close(3)                                = 0
open("/usr/lib/librt.so.1", O_RDONLY)   = -1 ENOENT (No such file or directory)

So not everything is well in emulation land, but we've run most of the
dynamic loader.  Sash segfaults.  I'm still pretty impressed; if no one
beats me to it I'll track it down next week.

On Thu, Jul 10, 2003 at 10:10:10PM +0200, Fabrice Bellard wrote:
> which version of x86 gcc do you use ? It seems to be a problem with x86 
> coge generator. Did you take my latest commit in exec.h ? The 'return' I 
> added in it does not seem to be generated in the x86 code.
> 
> Fabrice.
> 
> Daniel Jacobowitz wrote:
> >On Wed, Jul 09, 2003 at 09:49:33PM +0200, Fabrice Bellard wrote:
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>>I was just playing with the ARM support, it's great to see it taking
> >>>shape :)  Fabrice, are you still investigating it, or does it work for
> >>>you?  My local ARM setup crashes a few hundred instructions into ld.so;
> >>>a loop runs for too long and hits the top of the stack.
> >>>
> >>
> >>With my latest commits it is working: QEMU can launch dynamically linked 
> >>'ls' and 'bash' processes. I will provide soon a binary archive so that 
> >>people can at least try it if they have problems.
> >
> >
> >Still doesn't work here.  I've attached the debugging output if you're
> >curious; I won't have time to debug it properly until next week.  It
> >looks like something wrong with the conditional jump.
> >
> >
> >>Warning: no FPU emulation is done. I just added the necessary code to 
> >>skip the few FPU instructions present in the libc. If anyone has ideas 
> >>about FPU on ARM, I am interested. Unfortunately the Linux distributions 
> >>seem to use the kernel based NetWinder FPU emulator.
> >
> >
> >Yes; here we use userspace software floating point generally instead. 
> >Hardware which actually has the FPA unit is rare (is there any
> >supported?)
> >
> >
> >>I tested the ARM support with an ARM glibc-2.2.5 from a debian 3.0 
> >>installed on a StrongARM board.
> >
> >
> >My failing test is from a later version of glibc and GCC.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer