* [Qemu-devel] ARM @ 2003-07-09 18:35 Daniel Jacobowitz 2003-07-09 19:49 ` Fabrice Bellard 2003-07-09 19:53 ` Jocelyn Mayer 0 siblings, 2 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2003-07-09 18:35 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-09 18:35 [Qemu-devel] ARM Daniel Jacobowitz @ 2003-07-09 19:49 ` Fabrice Bellard 2003-07-10 16:17 ` Daniel Jacobowitz 2003-07-10 16:45 ` Laurent Desnogues 2003-07-09 19:53 ` Jocelyn Mayer 1 sibling, 2 replies; 9+ messages in thread From: Fabrice Bellard @ 2003-07-09 19:49 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-09 19:49 ` Fabrice Bellard @ 2003-07-10 16:17 ` Daniel Jacobowitz 2003-07-10 20:10 ` Fabrice Bellard 2003-07-10 16:45 ` Laurent Desnogues 1 sibling, 1 reply; 9+ messages in thread From: Daniel Jacobowitz @ 2003-07-10 16:17 UTC (permalink / raw) To: qemu-devel [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-10 16:17 ` Daniel Jacobowitz @ 2003-07-10 20:10 ` Fabrice Bellard 2003-07-10 23:24 ` Daniel Jacobowitz 0 siblings, 1 reply; 9+ messages in thread From: Fabrice Bellard @ 2003-07-10 20:10 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-10 20:10 ` Fabrice Bellard @ 2003-07-10 23:24 ` Daniel Jacobowitz 0 siblings, 0 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2003-07-10 23:24 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-09 19:49 ` Fabrice Bellard 2003-07-10 16:17 ` Daniel Jacobowitz @ 2003-07-10 16:45 ` Laurent Desnogues 2003-07-10 23:17 ` Daniel Jacobowitz 1 sibling, 1 reply; 9+ messages in thread From: Laurent Desnogues @ 2003-07-10 16:45 UTC (permalink / raw) To: qemu-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-10 16:45 ` Laurent Desnogues @ 2003-07-10 23:17 ` Daniel Jacobowitz 0 siblings, 0 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2003-07-10 23:17 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-09 18:35 [Qemu-devel] ARM Daniel Jacobowitz 2003-07-09 19:49 ` Fabrice Bellard @ 2003-07-09 19:53 ` Jocelyn Mayer 2003-07-10 8:44 ` Fabrice Bellard 1 sibling, 1 reply; 9+ messages in thread From: Jocelyn Mayer @ 2003-07-09 19:53 UTC (permalink / raw) To: qemu mailing list 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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] ARM 2003-07-09 19:53 ` Jocelyn Mayer @ 2003-07-10 8:44 ` Fabrice Bellard 0 siblings, 0 replies; 9+ messages in thread From: Fabrice Bellard @ 2003-07-10 8:44 UTC (permalink / raw) To: qemu-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-07-11 0:32 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-07-09 18:35 [Qemu-devel] ARM Daniel Jacobowitz 2003-07-09 19:49 ` Fabrice Bellard 2003-07-10 16:17 ` Daniel Jacobowitz 2003-07-10 20:10 ` Fabrice Bellard 2003-07-10 23:24 ` Daniel Jacobowitz 2003-07-10 16:45 ` Laurent Desnogues 2003-07-10 23:17 ` Daniel Jacobowitz 2003-07-09 19:53 ` Jocelyn Mayer 2003-07-10 8:44 ` Fabrice Bellard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).