I have attacked ld64 from a different direction. This is a long message, the gist of which is that I have partly backtracked the "unknown scattered relocation type 4" error message that is printed when compiling ghc-6.8.1 Topic: Why does ghc-6.8.1 fail on powerpc (G4 and G5) OS X 10.5 (Leopard) with XCode 3.0 ? (Bootstrapped with ghc-6.6.1 from OS 10.4 (Tiger)) obvious symptom: stage2 compiler segfaults, gdb reports:

Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe0100c in __dyld__dyld_start ()

The main error seen is "unknown scattered relocation type 4" during linking when building ghc. I have gone digging into the source code of the linker to see what causes this crytic message. I pulled the source of ld from http://www.opensource.apple.com/darwinsource/10.5/ The ld64-77.tar.gz package from apple has the message eminating from ./ld64-77/src/MachOReaderRelocatable.hpp It can be produced by two lines: pamac-cek10:src chrisk$ grep -C3 -nr "unknown scattered relocation type" . ./MachOReaderRelocatable.hpp-3162- printf("unexpected scattered relocation type PPC_RELOC_HI16_SECTDIFF\n"); ./MachOReaderRelocatable.hpp-3163- break; ./MachOReaderRelocatable.hpp-3164- default: ./MachOReaderRelocatable.hpp:3165: printf("unknown scattered relocation type %d\n", sreloc->r_type()); ./MachOReaderRelocatable.hpp-3166- } ./MachOReaderRelocatable.hpp-3167- } ./MachOReaderRelocatable.hpp-3168- return result; -- ./MachOReaderRelocatable.hpp-3367- // do nothing, already used via a look ahead ./MachOReaderRelocatable.hpp-3368- break; ./MachOReaderRelocatable.hpp-3369- default: ./MachOReaderRelocatable.hpp:3370: printf("unknown scattered relocation type %d\n", sreloc->r_type()); ./MachOReaderRelocatable.hpp-3371- } ./MachOReaderRelocatable.hpp-3372- } ./MachOReaderRelocatable.hpp-3373- return result; I now need to figure out which line is responsible for the error. It turns out only one of the lines can print "4". They are both the default case of switch statements: egrep -n 'switch|case|default|unknown scattered relocation type' MachOReaderRelocatable.hpp 3010: switch (sreloc->r_type()) { 3011: case PPC_RELOC_VANILLA: 3019: case PPC_RELOC_BR14: 3030: case PPC_RELOC_BR24: 3042: case PPC_RELOC_LO16_SECTDIFF: 3054: case PPC_RELOC_LO14_SECTDIFF: 3066: case PPC_RELOC_HA16_SECTDIFF: 3078: case PPC_RELOC_LO14: 3090: case PPC_RELOC_LO16: 3102: case PPC_RELOC_HA16: 3114: case PPC_RELOC_SECTDIFF: 3115: case PPC_RELOC_LOCAL_SECTDIFF: 3122: switch ( sreloc->r_length() ) { 3123: case 0: 3131: case 1: 3139: case 2: 3147: case 3: 3159: case PPC_RELOC_PAIR: 3161: case PPC_RELOC_HI16_SECTDIFF: 3164: default: 3165: printf("unknown scattered relocation type %d\n", sreloc->r_type()); 3307: switch (sreloc->r_type()) { 3308: case GENERIC_RELOC_VANILLA: 3323: case GENERIC_RELOC_SECTDIFF: 3324: case GENERIC_RELOC_LOCAL_SECTDIFF: 3332: switch ( sreloc->r_length() ) { 3333: case 0: 3334: case 3: 3336: case 1: 3340: case 2: 3366: case GENERIC_RELOC_PAIR: 3369: default: 3370: printf("unknown scattered relocation type %d\n", sreloc->r_type()); Where are these constants from? The first switch statement uses constants from under /usr/include via #include enum reloc_type_ppc { PPC_RELOC_VANILLA, /* generic relocation as discribed above */ PPC_RELOC_PAIR, /* the second relocation entry of a pair */ PPC_RELOC_BR14, /* 14 bit branch displacement (to a word address) */ PPC_RELOC_BR24, /* 24 bit branch displacement (to a word address) */ PPC_RELOC_HI16, /* a PAIR follows with the low half */ PPC_RELOC_LO16, /* a PAIR follows with the high half */ PPC_RELOC_HA16, /* Same as the RELOC_HI16 except the low 16 bits and the * high 16 bits are added together with the low 16 bits * sign extened first. This means if bit 15 of the low * 16 bits is set the high 16 bits stored in the * instruction will be adjusted. */ PPC_RELOC_LO14, /* Same as the LO16 except that the low 2 bits are not * stored in the instruction and are always zero. This * is used in double word load/store instructions. */ PPC_RELOC_SECTDIFF, /* a PAIR follows with subtract symbol value */ PPC_RELOC_PB_LA_PTR,/* prebound lazy pointer */ PPC_RELOC_HI16_SECTDIFF, /* section difference forms of above. a PAIR */ PPC_RELOC_LO16_SECTDIFF, /* follows these with subtract symbol value */ PPC_RELOC_HA16_SECTDIFF, PPC_RELOC_JBSR, PPC_RELOC_LO14_SECTDIFF, PPC_RELOC_LOCAL_SECTDIFF /* like PPC_RELOC_SECTDIFF, but the symbol referenced was local. */ }; So here the 4th one is PPC_RELOC_HI16 and this is not handled in the first switch statement! The other switch is over /usr/include/mach-o/reloc.h 's : enum reloc_type_generic { GENERIC_RELOC_VANILLA, /* generic relocation as discribed above */ GENERIC_RELOC_PAIR, /* Only follows a GENERIC_RELOC_SECTDIFF */ GENERIC_RELOC_SECTDIFF, GENERIC_RELOC_PB_LA_PTR, /* prebound lazy pointer */ GENERIC_RELOC_LOCAL_SECTDIFF }; Here the 4th value is GENERIC_RELOC_LOCAL_SECTDIFF. This is handled by the switch (though I note that GENERIC_RELOC_PB_LA_PTR is not recognized). Thus it looks like the error relates to the presence of PPC_RELOC_HI16 segments in the object files being linked by ld. I will now look at the rest of the ld code to see what does mention PPC_RELOC_HI16. The PPC_RELOC_HI16 is handled in only one place in the MachOReaderRelocatable.hpp file. The handled and unhandled code paths depend on the value of the "scattered" flag, and are different branches of an if-else in the function: bool Reader<A>::addRelocReference_powerpc(const macho_section<typename A::P>* sect, const macho_relocation_info<typename A::P>* reloc) There is an early if-else test (reloc->r_address() & R_SCATTERED) == 0 The R_SCATTERED is defined in /usr/include/reloc.h: #define R_SCATTERED 0x80000000 /* mask to be applied to the r_address field The rest of reloc.h defines the bit batterns that are abstracted by the template classes MachOFileAbstraction.hpp which provide r_address(). ( macho_relocation_info and macho_scattered_relocation_info classes) So it looks like the addRelocReference_powerpc cannot handle a scattered PPC_RELOC_HI16 type. Looking at the rest of the code, I see that MachOWriterExecutable.hpp has a function: template <typename A> uint32_t Writer<A>::addObjectRelocs_powerpc(ObjectFile::Atom* atom, ObjectFile::Reference* ref) ...which can create a type PPC_RELOC_HI16 with the scattered flag set to true (see line 2904). Thus it seems that the ld program has code to create a situation (scattered is true && type is PPC_RELOC_HI16) that it cannot handle. This does not mean that ld is responsible for creating the scattered PPC_RELOC_HI16. And since I now know what to look for, I go digging with 'otool -r' and 'otool -v -r' which quickly verifies that HI16 is type 4 and that many of the ".o" files under ./ghc-6.8.1/libraries/base/dist/build do have scattered HI16 relocations. And now I need to quit this for tonight.

Deborah Goldsmith wrote:

I asked internally at Apple about this and got the following response:

...

...

...

obvious symptom: stage2 compiler segfaults, gdb reports:

...

Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe0100c in __dyld__dyld_start ()

Ignore that. `continue` to actually run the program and get to the real error.

Deborah

Ah, thanks. It seems stage2/ghc-inplace may be a bit stripped, but stage2/ghc-6.8.1 gives a legible backtrace:

pamac-cek10:stage2 chrisk$ gdb ghc-6.8.1 GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:11:19 UTC 2007) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"... warning: Unable to read symbols for "GNUreadline.framework/Versions/A/GNUreadline" (file not found).

warning: Unable to read symbols for "GMP.framework/Versions/A/GMP" (file not found). Reading symbols for shared libraries ... done

(gdb) run --make /tmp/t.hs -o /tmp/t Starting program: /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compiler/stage2/ghc-6.8.1 --make /tmp/t.hs -o /tmp/t Reading symbols for shared libraries +..+... done

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x4082000c 0x012ba9c8 in stg_ap_p_fast ()

(gdb) bt #0 0x012ba9c8 in stg_ap_p_fast () #1 0x010d79ec in base_GHCziIOBase_noDuplicate_info () #2 0x01290e58 in schedule (initialCapability=0x41810070, task=0x38600000) at Schedule.c:621 #3 0x012933c8 in scheduleWaitThread (tso=0x2680000, ret=0x0, cap=0x14c4318) at Schedule.c:2500 #4 0x01285040 in rts_evalIO (cap=0x14c4318, p=0x13f40b4, ret=0x0) at RtsAPI.c:476 #5 0x0129d310 in ioManagerStart () at posix/Signals.c:151 #6 0x0128841c in hs_init (argc=0xbffff4a8, argv=0xbffff4ac) at RtsStartup.c:279 #7 0x01288464 in startupHaskell (argc=5, argv=0xbffff594, init_root=0x113cc <__stginit_ZCMain>) at RtsStartup.c:290 #8 0x0127ebbc in real_main () at Main.c:57 #9 0x0127ed1c in main (argc=5, argv=0xbffff594) at Main.c:153

(gdb) disassemble Dump of assembler code for function stg_ap_p_fast: 0x012ba9b0 : andi. r31,r14,3 And Immediate (to get the two least significant bits of r14) 0x012ba9b4 : cmpwi r31,1 Equiv. to cmpi 0,0,r31,1 Compare Immediate 0x012ba9b8 : beq- 0x12ba9e0 Branch if equal (not taken, obviously, since the the next instructions are the fatal ones) 0x012ba9bc : li r31,-4 Load Immediate (I believe -4 is the opposite bit pattern to 3) 0x012ba9c0 : and r14,r14,r31 AND (to clear the two least significant bits of r14) 0x012ba9c4 : lwz r31,0(r14) Load Word and Zero 0x012ba9c8 : lha r31,-4(r31) [ The error was for the above operation: Load Halfword Algebraic destination general purpose register r31

A quick descent of the stack prints the single source lines: Initial frame selected; you cannot go up. (gdb) down #8 0x0127ebbc in real_main () at Main.c:57 57 startupHaskell(progargc,progargv,__stginit_ZCMain); (gdb) down #7 0x01288464 in startupHaskell (argc=5, argv=0xbffff594, init_root=0x113cc <__stginit_ZCMain>) at RtsStartup.c:290 290 hs_init(&argc, &argv); (gdb) down #6 0x0128841c in hs_init (argc=0xbffff4a8, argv=0xbffff4ac) at RtsStartup.c:279 279 ioManagerStart(); (gdb) down #5 0x0129d310 in ioManagerStart () at posix/Signals.c:151 151 rts_evalIO(cap,&base_GHCziConc_ensureIOManagerIsRunning_closure,NULL); (gdb) down #4 0x01285040 in rts_evalIO (cap=0x14c4318, p=0x13f40b4, ret=0x0) at RtsAPI.c:476 476 return scheduleWaitThread(tso,ret,cap); (gdb) down #3 0x012933c8 in scheduleWaitThread (tso=0x2680000, ret=0x0, cap=0x14c4318) at Schedule.c:2500 2500 cap = schedule(cap,task); (gdb) down #2 0x01290e58 in schedule (initialCapability=0x41810070, task=0x38600000) at Schedule.c:621 621 r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r); (gdb) print r $1 = (StgRegTable *) 0xabdffffc (gdb) print &cap->r $5 = (StgRegTable *) 0x7ddf7380 (gdb) print stg_returnToStackTop $2 = {} 0x12b3784 (gdb) down #1 0x010d79ec in base_GHCziIOBase_noDuplicate_info () (gdb) down #0 0x012ba9c8 in stg_ap_p_fast () (gdb) down Bottom (i.e., innermost) frame selected; you cannot go down. And disassemle the fatality source -4 displaced r31 ]

0x012ba9cc : rlwinm r31,r31,2,0,29 0x012ba9d0 : addis r31,r31,313 0x012ba9d4 : lwz r31,-28940(r31) 0x012ba9d8 : mtctr r31 0x012ba9dc : bctr 0x012ba9e0 : addi r22,r22,0 0x012ba9e4 : lwz r31,-1(r14) 0x012ba9e8 : mtctr r31 0x012ba9ec : bctr 0x012ba9f0 : addi r22,r22,-8 0x012ba9f4 : stw r15,4(r22) 0x012ba9f8 : b 0x12b666c 0x012ba9fc : lwz r31,0(r14) 0x012baa00 : lha r31,-10(r31) 0x012baa04 : cmplwi r31,0 0x012baa08 : bgt- 0x12baa88 0x012baa0c : li r3,0 0x012baa10 : li r4,2441 0x012baa14 : bl 0x1287c80 <_assertFail> 0x012baa18 : cmpwi r31,1 0x012baa1c : beq- 0x12baac8 0x012baa20 : addi r22,r22,-8 0x012baa24 : stw r15,4(r22) 0x012baa28 : cmplwi r31,4 0x012baa2c : blt- 0x12baa8c 0x012baa30 : li r30,16 0x012baa34 : add r25,r25,r30 0x012baa38 : cmplw r25,r26 0x012baa3c : bgt- 0x12baa94 0x012baa40 : addi r29,r25,4 0x012baa44 : subf r30,r30,r29 0x012baa48 : lis r29,298 0x012baa4c : ori r29,r29,60928 0x012baa50 : stw r29,0(r30) 0x012baa54 : addi r31,r31,-1 0x012baa58 : sth r31,4(r30) 0x012baa5c : stw r14,8(r30) 0x012baa60 : li r31,1 0x012baa64 : sth r31,6(r30) 0x012baa68 : li r31,0 0x012baa6c : cmplwi r31,1 0x012baa70 : blt- 0x12baaa8 0x012baa74 : mr r14,r30 0x012baa78 : addi r22,r22,8 0x012baa7c : lwz r31,0(r22) 0x012baa80 : mtctr r31 0x012baa84 : bctr 0x012baa88 : b 0x12baa18 0x012baa8c : add r14,r14,r31 0x012baa90 : b 0x12baa30 0x012baa94 : stw r30,112(r27) 0x012baa98 : lis r31,299 0x012baa9c : ori r31,r31,26220 0x012baaa0 : stw r31,0(r22) 0x012baaa4 : b 0x12af8ac <__stg_gc_enter_1> 0x012baaa8 : addi r29,r31,1 0x012baaac : rlwinm r29,r29,2,0,29 0x012baab0 : lwzx r29,r22,r29 0x012baab4 : addi r28,r30,12 0x012baab8 : rlwinm r23,r31,2,0,29 0x012baabc : stwx r29,r28,r23 0x012baac0 : addi r31,r31,1 0x012baac4 : b 0x12baa6c 0x012baac8 : addi r22,r22,0 0x012baacc : addi r14,r14,1 0x012baad0 : li r31,-4 0x012baad4 : and r31,r14,r31 0x012baad8 : lwz r31,0(r31) 0x012baadc : mtctr r31 0x012baae0 : bctr 0x012baae4 : b 0x12baae4 End of assembler dump.

Where was the evil value in r14 filled in? I look up the stack and disassemble, but never find the instructions which assign to r14. The must be in another subroutine (?). What about printing stuff? #2 0x01290e58 in schedule (initialCapability=0x41810070, task=0x38600000) at Schedule.c:621 621 r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r); (gdb) list 616 break; 617 618 case ThreadRunGHC: 619 { 620 StgRegTable *r; 621 r = StgRun((StgFunPtr) stg_returnToStackTop, &cap->r); 622 cap = regTableToCapability(r); 623 ret = r->rRet; 624 break; 625 } #3 0x012933c8 in scheduleWaitThread (tso=0x2680000, ret=0x0, cap=0x14c4318) at Schedule.c:2500 2500 cap = schedule(cap,task); (gdb) print *cap $8 = { f = { stgGCEnter1 = 0x12af8ac <__stg_gc_enter_1>, stgGCFun = 0x12aff54 <__stg_gc_fun> }, r = { rR1 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR2 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR3 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR4 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR5 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR6 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR7 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR8 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR9 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rR10 = { w = 0, a = 0x0, c = 0, i8 = 0 '\0', f = 0, i = 0, p = 0x0, cl = 0x0, offset = 0, b = 0x0, t = 0x0 }, rF1 = 0, rF2 = 0, rF3 = 0, rF4 = 0, rD1 = 0, rD2 = 0, rL1 = 0, rSp = 0x0, rSpLim = 0x0, rHp = 0x0, rHpLim = 0x0, rCurrentTSO = 0x2680000, rNursery = 0x24004d0, rCurrentNursery = 0x2600fe0, rCurrentAlloc = 0x2601000, rHpAlloc = 0, rmp_tmp_w = 0, rmp_tmp1 = { _mp_alloc = 0, _mp_size = 0, _mp_d = 0x0 }, rmp_tmp2 = { _mp_alloc = 0, _mp_size = 0, _mp_d = 0x0 }, rmp_result1 = { _mp_alloc = 0, _mp_size = 0, _mp_d = 0x0 }, rmp_result2 = { _mp_alloc = 0, _mp_size = 0, _mp_d = 0x0 }, rRet = 0, rSparks = { base = 0x2362000, lim = 0x2366000, hd = 0x2362000, tl = 0x2362000 } }, no = 0, running_task = 0x2400580, in_haskell = rtsTrue, run_queue_hd = 0x14076d0, run_queue_tl = 0x14076d0, suspended_ccalling_tasks = 0x0, mut_lists = 0x2400320, spare_workers = 0x0, lock = { __sig = 1297437784, __opaque = '\0' , "\b", '\0' }, returning_tasks_hd = 0x0, returning_tasks_tl = 0x0, wakeup_queue_hd = 0x14076d0, wakeup_queue_tl = 0x14076d0, free_tvar_watch_queues = 0x14076c0, free_invariant_check_queues = 0x14076c4, free_trec_chunks = 0x14076c8, free_trec_headers = 0x14076cc, transaction_tokens = 0 } (gdb) print task $10 = (Task *) 0x2400580 (gdb) print *task $11 = { id = 0xa032c074, cap = 0x14c4318, stopped = rtsFalse, suspended_tso = 0x0, tso = 0x2680000, stat = NoStatus, ret = 0x0, cond = { __sig = 1129270852, __opaque = '\0' , "\002" }, lock = { __sig = 1297437784, __opaque = '\0' , "\b", '\0' }, wakeup = rtsFalse, elapsedtimestart = 1195167550991792, muttimestart = 12791, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 0, prev = 0x0, next = 0x0, return_link = 0x0, all_link = 0x0, prev_stack = 0x0 } (gdb) print *tso $13 = { header = { info = 0x12b3464 }, link = 0x14076d0, global_link = 0x14076d0, what_next = 1, why_blocked = 0, flags = 1, block_info = { closure = 0x0, tso = 0x0, fd = 0, target = 0 }, id = 1, saved_errno = 0, bound = 0x2400580, cap = 0x14c4318, trec = 0x14076cc, blocked_exceptions = 0x14076d0, stack_size = 241, max_stack_size = 2080753, sp = 0x26803ec, stack = 0x268003c } (gdb) list (with list - and list -) 2475 Task *task; 2476 2477 // We already created/initialised the Task 2478 task = cap->running_task; 2479 2480 // This TSO is now a bound thread; make the Task and TSO 2481 // point to each other. 2482 tso->bound = task; 2483 tso->cap = cap; 2484 2485 task->tso = tso; 2486 task->ret = ret; 2487 task->stat = NoStatus; 2488 2489 appendToRunQueue(cap,tso); 2490 2491 debugTrace(DEBUG_sched, "new bound thread (%lu)", (unsigned long)tso->id); 2492 2493 #if defined(GRAN) 2494 /* GranSim specific init */ 2495 CurrentTSO = m->tso; // the TSO to run 2496 procStatus[MainProc] = Busy; // status of main PE 2497 CurrentProc = MainProc; // PE to run it on 2498 #endif 2499 2500 cap = schedule(cap,task); 2501 2502 ASSERT(task->stat != NoStatus); 2503 ASSERT_FULL_CAPABILITY_INVARIANTS(cap,task); 2504 #4 0x01285040 in rts_evalIO (cap=0x14c4318, p=0x13f40b4, ret=0x0) at RtsAPI.c:476 476 return scheduleWaitThread(tso,ret,cap); (gdb) print p $16 = (HaskellObj) 0x13f40b4 (gdb) print *p $17 = { header = { info = 0x12b3324 }, payload = 0x13f40b8 } (gdb) list 471 rts_evalIO (Capability *cap, HaskellObj p, /*out*/HaskellObj *ret) 472 { 473 StgTSO* tso; 474 475 tso = createStrictIOThread(cap, RtsFlags.GcFlags.initialStkSize, p); 476 return scheduleWaitThread(tso,ret,cap); 477 } 478 479 /* 480 * rts_evalStableIO() is suitable for calling from Haskell. It #5 0x0129d310 in ioManagerStart () at posix/Signals.c:151 151 rts_evalIO(cap,&base_GHCziConc_ensureIOManagerIsRunning_closure,NULL); (gdb) list 146 { 147 // Make sure the IO manager thread is running 148 Capability *cap; 149 if (io_manager_pipe < 0) { 150 cap = rts_lock(); 151 rts_evalIO(cap,&base_GHCziConc_ensureIOManagerIsRunning_closure,NULL); 152 rts_unlock(cap); 153 } 154 } 155 #endif And this is the limit of what I can do with gdb for now.

There are two possible avenues to proceed along. The first is to figure out from the crashing stage2 compiler what is going wrong to cause the segfault. But I think this compiler was created in a broken state. The "unknown relocation error 4" from the new 'ld' in 10.5 means it sees but cannot handle scattered PPC_RELOC_HI16 segments. I am guessing that the stage2 compiler is linked wrong, which may be why it ends up with a bad address and the error:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x4082000c

I do not think I know enough about compilers and linkers to write a good bug report to Apple about the fact that 'ld' seems (to me) to write scattered PPC_RELOC_HI16 segments which it cannot read and recognize. Corey O'Conner : you are debugging ld as well. Does the 'ld' code look broken to you (as detailed in my earlier reply to your message) ? Cheers, Chris Simon Marlow wrote:

The crash is in Haskell code, so the C backtrace is not to be trusted. Actually in this case it looks correct up to schedule(), and the uppermost frame is probably correct - the crash was really in stg_ap_p_fast, but in between is garbage (base_GHCziIOBase_noDuplicate_info).

Looks like you're making good progress here, though! Working backwards from the crash and try to find out where the erroneous memory access originated is the next step. The wiki page has some useful tips:

http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes

Cheers, Simon