Re: [Pkg-mono-group] Bug#394418: v3 v4 question

[Phil Blundell <pb@reciva.com>]

On Mon, 2006-10-30 at 00:39 +0100, Mirco Bauer wrote:
> So we are back to, it never failed to build on cats, but always did on netwinder.

Mm, strange.  I tried to build it by hand on smackdown and it failed
again there:

Creating ../../build/deps/net_2_0_corlib.dll.makefrag ...
make[8]: Leaving directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
make[8]: Entering directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
/usr/bin/make all-local
make[9]: Entering directory `/var/tmp/mono-1.1.18/mcs/class/corlib'
MONO_PATH="../../class/lib/net_2_0_bootstrap:
$MONO_PATH" /var/tmp/mono-1.1.18/runtime/mono-wrapper  ../../gmcs/gmcs.exe /codepage:65001 -nowarn:169,612,618,649 -d:INSIDE_CORLIB -nowarn:414  -d:NET_1_1 -d:NET_2_0 -debug /noconfig -unsafe -nostdlib -resource:resources/collation.core.bin -resource:resources/collation.tailoring.bin -resource:resources/collation.cjkCHS.bin -resource:resources/collation.cjkCHT.bin -resource:resources/collation.cjkJA.bin -resource:resources/collation.cjkKO.bin -resource:resources/collation.cjkKOlv2.bin -target:library -out:mscorlib.dll  @corlib.dll.sources

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

mono: unhandled page fault at pc=0x0012e448, lr=0x000dc204 (bad
address=0x00000084, code 0)
pc : [<0012e448>]    lr : [<000dc204>]    Not tainted
sp : bf5ff69c  ip : bf5ff670  fp : bf5ff6cc
r10: 4011c000  r9 : bf5ff778  r8 : bf5ff6f8
r7 : 00000024  r6 : 00000000  r5 : bf5ff6d0  r4 : bf5ffbe0
r3 : 00000000  r2 : 4011cca0  r1 : 00000000  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: 3CBD17F  Table: 03CBD17F  DAC: 00000015

0012e414 <sigusr1_signal_handler>:
  12e414:       e1a0c00d        mov     ip, sp
  12e418:       e92dd810        stmdb   sp!, {r4, fp, ip, lr, pc}
  12e41c:       e24cb004        sub     fp, ip, #4      ; 0x4
  12e420:       e24dd020        sub     sp, sp, #32     ; 0x20
  12e424:       e50b0028        str     r0, [fp, #-40]
  12e428:       e50b102c        str     r1, [fp, #-44]
  12e42c:       e50b2030        str     r2, [fp, #-48]
  12e430:       ebfd81aa        bl      8eae0 <mono_thread_current>
  12e434:       e1a03000        mov     r3, r0
  12e438:       e50b301c        str     r3, [fp, #-28]
  12e43c:       e51b3030        ldr     r3, [fp, #-48]
  12e440:       e50b3014        str     r3, [fp, #-20]
  12e444:       e51b301c        ldr     r3, [fp, #-28]
  12e448:       e5d33084        ldrb    r3, [r3, #132]
  12e44c:       e3530000        cmp     r3, #0  ; 0x0

At a first glance this looks more like a TLS emulation kind of problem
than an instruction set discrepancy.  But it'd take a bit more detective
work to figure out what's really going wrong, and I guess there is no
guarantee that this is the same problem the netwinders are seeing in any
case.

p.