[Openmcl-devel] logxor miscompilation on (android?)arm
Gary Byers
gb at clozure.com
Wed Nov 23 06:48:25 PST 2011
That (the original crash) has to do with how lisp code calls into the
runtime (and the fact that the Android runtime is at a different fixed
address than the canonical fixed address.) When we cross-compile,
we adjust for that; when we try to build a native image on Android,
we erroneously adjust for it again, and wind up at 0x07FFF700. I could
possibly figure out how to bias runtime addresses the right number of
times, but (for this and other reasons) it seems better to change the
scheme. That'll probably take a few days, but I think that it's worth
doing.
If the kernel debugger is entered when the --batch option is in effect
(as it is when the image is bootstrapped), it tries to print some diagnostic
info and quit. If it gets some sort of memory fault when printing that info,
the kernel debugger is entered and it tries to print some diagnostic information.
(You will eventually die with an unhandled stack overflow, but enough stuff
-does- get printed that that takes a while.) That's really stupid, and I
hope that there's some way to blame it on Android.
On Wed, 23 Nov 2011, Stas Boukarev wrote:
> Gary Byers <gb at clozure.com> writes:
>
>> Repeat after me: "ARM bug".
>>
>> I was going to say something like "for something that's only a little over a
>> year old and that hasn't had a whole lot of use, the CCL ARM port is pretty
>> mature and stable", but I wasn't sure if people'd believe that.
>>
>> If anyone needs convincing: this bug was present in the PPC backend (and
>> merely inherited by the ARM) and is likely over 15 years old. (Mature,
>> stable, but wrong in this case ...)
>>
>> Fixed in the trunk in r15088.
> Thanks, that fixes ironclad not working properly.
>
> But I'm unable to do rebuild-ccl
> ;Wrote bootstrapping image: #P"/data/ccl/aarm-boot"
>
>> Error: Errors (:SIGNALED 7) reloading boot image:
>> Unhandled exception 11 at 0x7fff700, context->regs at #xbef5d6d8
>> received signal 0; faulting address: 0x7fff700
>> Main thread pid 374
>> Current Thread Context Record (tcr) = 0xa430
>> Control (C) stack area: low = 0xbedfb000, high = 0xbef5db70
>> Value (lisp) stack area: low = 0x40001000, high = 0x4014d000
>> Exception stack pointer = 0xbef5d9a0
>> r00 = 0x00000013 r08 = 0x54069D86
>> r01 = 0x00000002 r09 = 0x54069D86
>> r02 = 0x00000004 r10 = 0x4014CFB4
>> r03 = 0x0000A430 r11 = 0x00000000
>> r04 = 0x54000006 r12 = 0x5407FFF8
>> r05 = 0x0000A3D8 r13 = 0xBEF5D9A0
>> r06 = 0x4014CFCC r14 = 0x50010B80
>> r07 = 0x54000000 r15 = 0x07FFF700
>> rcontext = 0xA430
>> nargs = 1
>> r11 (fn) = 0
>> r04 (arg_z) = #(16779280)
>> r05 (arg_y) = 10486
>> r06 (arg_x) = 268776435
>> r07 (temp0) = 352321536
>> r08 (temp1/fname/next_method_context) = #<Anonymous Function #x54069d86>
>> r09 (temp2/nfn) = #<Anonymous Function #x54069d86>
>> s00 = -1.052551e-01 (0xbdd79000) s01 = 1.000000e+00 (0x3f800000)
>> d00 = 7.812506e-03 (0x3f800000bdd79000)
>> s02 = -1.052551e-01 (0xbdd79000) s03 = 0.000000e+00 (0x00000000)
>> d01 = 1.573609e-314 (0x0000000bdd79000)
>> s04 = 0.000000e+00 (0x00000000) s05 = 0.000000e+00 (0x00000000)
>> d02 = 0.000000e+00 (0x000000000000000)
>> s06 = 0.000000e+00 (0x00000000) s07 = 0.000000e+00 (0x00000000)
>> d03 = 0.000000e+00 (0x000000000000000)
>> s08 = 0.000000e+00 (0x00000000) s09 = 0.000000e+00 (0x00000000)
>> d04 = 0.000000e+00 (0x000000000000000)
>> s10 = 0.000000e+00 (0x00000000) s11 = 0.000000e+00 (0x00000000)
>> d05 = 0.000000e+00 (0x000000000000000)
>> s12 = 0.000000e+00 (0x00000000) s13 = 0.000000e+00 (0x00000000)
>> d06 = 0.000000e+00 (0x000000000000000)
>> s14 = 3.215980e-42 (0x000008f7) s15 = 0.000000e+00 (0x00000000)
>> d07 = 1.133881e-320 (0x0000000000008f7)
>> s16 = 0.000000e+00 (0x00000000) s17 = 0.000000e+00 (0x00000000)
>> d08 = 0.000000e+00 (0x000000000000000)
>> s18 = 0.000000e+00 (0x00000000) s19 = 0.000000e+00 (0x00000000)
>> d09 = 0.000000e+00 (0x000000000000000)
>> s20 = 0.000000e+00 (0x00000000) s21 = 0.000000e+00 (0x00000000)
>> d10 = 0.000000e+00 (0x000000000000000)
>> s22 = 0.000000e+00 (0x00000000) s23 = 0.000000e+00 (0x00000000)
>> d11 = 0.000000e+00 (0x000000000000000)
>> s24 = 0.000000e+00 (0x00000000) s25 = 0.000000e+00 (0x00000000)
>> d12 = 0.000000e+00 (0x000000000000000)
>> s26 = 0.000000e+00 (0x00000000) s27 = 0.000000e+00 (0x00000000)
>> d13 = 0.000000e+00 (0x000000000000000)
>> s28 = 0.000000e+00 (0x00000000) s29 = 0.000000e+00 (0x00000000)
>> d14 = 0.000000e+00 (0x000000000000000)
>> s30 = 0.000000e+00 (0x00000000) s31 = 0.000000e+00 (0x00000000)
>> d15 = 0.000000e+00 (0x000000000000000)
>> FPSCR = 0x80000000
>> Lisp memory areas:
>> code low high
>> dynamic (9) 0x5405f4b0 0x55060000
>> dynamic (9) 0x5405f4b0 0x5405f4b0
>> dynamic (9) 0x5405f4b0 0x5405f4b0
>> dynamic (9) 0x54000000 0x5405f4b0
>> static (8) 0x3fff000 0x4001000
>> managed static (7) 0x52000000 0x52000000
>> readonly (4) 0x50000000 0x52000000
>> vstack (2) 0x40001000 0x4014d000
>> cstack (1) 0xbedfb000 0xbef5db70
>> Lisp kernel svn revision: unknown
>> Can't find symbol.
>> current thread: tcr = 0xa430, native thread ID = 0x176, interrupts disabled
>>
>>
>> (#xBEF5D9A0) #x04004444 : (subprimitive ret1valn)
>> (#xBEF5D9B0) #x50010CE4 : #<Function WALK-DYNAMIC-AREA #x54009e26> + 128
>> (#xBEF5D9E0) #x50010C84 : #<Function WALK-DYNAMIC-AREA #x54009e26> + 32
>> (#xBEF5DA38) #x5009CF34 : #<Function %MAP-AREAS #x5403cbde> + 616
>> (#xBEF5DA48) #x500AEA54 : #<Anonymous Function #x54044e6e> + 848
>> (#xBEF5DA58) #x0400E274 : (subprimitive (null))
>> (#xBEF5DA88) #x0400E264 : (subprimitive (null))
>> (#xBEF5DAE0) #x0400E304 : (subprimitive (null))
>
> And it prints 3M of similar stuff.
>
> --
> With best regards, Stas.
>
>
More information about the Openmcl-devel
mailing list