I'm trying to debug an ld crash that occurs when building GHC on a PPC Mac under 10.5. I've forwarded the thread from the GHC Users mailing list below.
Basically, what looks like is happening is that getAddress is being called on an instance of Atom which has not had it's fSection data member set. This results in a NULL pointer dereference.
I'd like to debug this but don't really want to have to hack apart GHC and collect2 just to figure out how to launch ld under the right environment to reproduce the situation in which it crashed. Is there an easier way?
---------- Forwarded message ----------
From:
Corey O'Connor <
email@hidden>
Date: Nov 11, 2007 2:00 PM
Subject: Re: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5
To: Chris Kuklewicz <
email@hidden>
Cc:
email@hiddenSplit objects does seem to be the source of the crash. With it disabled the compile of Parsec succeeds but linking of System fails due to "unknown scattered relocation type 4."
I decided to compile the ld tool with debugging to see if I can get more information when ld crashes. Here's what I've found out so far:
The ld executable used is actually from the ld64 project and not the cctools project. The cctools' ld is installed as ld_classic on OS X. In theory this should be the same linker as on Tiger and could be used instead of the ld from ld64. That might be a good workaround till ld is fixed: Update ghc's SysTools to use ld_classic instead of ld.
1. Once ld from ld64 is compiled for debug swap out the production ld with the version with debug symbols.
2. ulimit -c unlimited
3. Run ghc's make once again.
4. Load the core dump in GCC
This gives the interesting back trace:
#0 0x000222ac in ObjectFile::Section::getBaseAddress (this=0x0) at ObjectFile.h:182
#1 0x000224a0 in ObjectFile::Atom::getAddress (this=0x6decb0) at ObjectFile.h:269
#2 0x000c3a30 in mach_o::executable::Writer<ppc>::addObjectRelocs_powerpc (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at
MachOWriterExecutable.hpp:2742
#3 0x0001309c in mach_o::executable::Writer<ppc>::addObjectRelocs (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at MachOWriterExecutable.hpp:2678
#4 0x001ab3e4 in mach_o::executable::Writer<ppc>::buildObjectFileFixups (this=0x6f65a0) at
MachOWriterExecutable.hpp:3065
#5 0x001be094 in mach_o::executable::Writer<ppc>::buildFixups (this=0x6f65a0) at MachOWriterExecutable.hpp:2398
#6 0x001be108 in mach_o::executable::Writer<ppc>::buildLinkEdit (this=0x6f65a0) at
MachOWriterExecutable.hpp:1834
#7 0x001be238 in mach_o::executable::Writer<ppc>::write (this=0x6f65a0, atoms=@0xbffef940, stabs=@0xbffef9c4, entryPointAtom=0x0, dyldHelperAtom=0x0, createUUID=false, canScatter=false, cpuConstraint=ObjectFile::Reader::kCpuAny, biggerThanTwoGigs=false) at
MachOWriterExecutable.hpp:1814
#8 0x0000fec4 in Linker::writeOutput (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:2700
#9 0x0001f5b0 in Linker::link (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:585
#10 0x0002113c in main (argc=465, argv=0xbffefb88) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:3568
Looks like a NULL pointer dereference. Why the pointer is NULL I don't know but that's what I have so far.
-Corey
On Nov 11, 2007 7:33 AM, Chris Kuklewicz <
email@hidden
> wrote:
Ian Lynagh wrote:
> On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote:
>> Anytime I see the linker crash I get nervous. Any clues on where to start
>> debugging?
>
> Is it deterministic? A hardware fault, e.g. bad RAM, seems likely to me.
>
>
> Thanks
> Ian
10.5 / XCode 3.0 on a single G4 ppc computer (powerbook).
I fear the new Apply toolchain is choking on something, possible split-objs?
--
Chris Kuklewicz
--
-Corey O'Connor