GHC 6.8.1 on powerpc OS X 10.5
So I decided to try and route around the ld/collect2 problems with ghc-6.8.1 not working on powerpc OS X 10.5 OS X 10.5 (Leopard) uses XCode 3.0 which has a gcc-4.0 toolchain. So I try to get another gcc & binutils from macports. This failed. All of gcc40 gcc41 gcc42 and gcc43 failed to compile successfully with macports. So I switched to trying fink, which offers gcc-4.2.2 and this did compile and install. Hooray. Unfortunately, using ghc-6.6.1 (from when I ran OS 10.4 Tiger) with gcc-4.2.2 does not work when compiling ghc-6.8.1 (at least on this platform).
------------------------------------------------------------------------ == make boot -r; in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compiler ------------------------------------------------------------------------ ../utils/mkdirhier/mkdirhier stage1 for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn vectorise specialise simplCore stranal stgSyn simplStg codeGen main profiling parser cprAnalysis ndpFlatten iface cmm nativeGen; do \ ../utils/mkdirhier/mkdirhier stage1/$i; \ done Creating stage1/ghc_boot_platform.h... Done. ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl /bin/sh: line 1: 59384 Illegal instruction ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl make[1]: *** [primop-tag.hs-incl] Error 132 make[1]: *** Deleting file `primop-tag.hs-incl' make: *** [stage1] Error 1
Running "../utils/genprimopcode/genprimopcode --primop-tag" produces "Illegal instruction" There were other odd messages during the make,such as in this early output:
------------------------------------------------------------------------ == make boot -r; in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compat ------------------------------------------------------------------------ ../utils/mkdependC/mkdependC -f .depend -I. -Iinclude -I../includes -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=1 -I../libraries/base/cbits -I../libraries/base/include -- cbits/directory.c cbits/rawSystem.c cbits/unicode.c /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Compat/Unicode.hs Distribution/Compat/Directory.hs Distribution/Compat/Exception.hs Distribution/Compat/Map.hs Distribution/Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Compat/TempFile.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Simple/Program.hs Distribution/Simple/Utils.hs Distribution/System.hs Distribution/Verbosity.hs Distribution/Version.hs Language/Haskell/Extension.hs System/FilePath.hs System/FilePath/Posix.hs System/FilePath/Windows.hs Trace/Hpc/Mix.hs Trace/Hpc/Tix.hs Trace/Hpc/Util.hs <<ghc: 36490248 bytes, 5 GCs, 130248/130248 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.01 elapsed), 0.22 MUT (4.47 elapsed), 0.06 GC (0.43 elapsed) :ghc>> make all /usr/local/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi gcc: unrecognized option '-no-cpp-precomp'
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: section difference relocatable subtraction expression, "_s2tx_0_alt" minus "_s2tx_info" using a symbol at the end of section will not produce an assembly time constant
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = _s2tx_0_alt - _s2tx_info
The '-no-cpp-precomp' and 'section difference ...' and 'use a symbol ...' messages repeat often. I looked at trac, and can only find the closed ticket http://hackage.haskell.org/trac/ghc/ticket/1427 relating to gcc-4.2 issues. Does anyone have suggestions? hints? bad jokes? -- Chris K
Chris Kuklewicz wrote:
Running "../utils/genprimopcode/genprimopcode --primop-tag" produces "Illegal instruction"
There were other odd messages during the make,such as in this early output:
------------------------------------------------------------------------ == make boot -r; in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compat ------------------------------------------------------------------------ ../utils/mkdependC/mkdependC -f .depend -I. -Iinclude -I../includes -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=1 -I../libraries/base/cbits -I../libraries/base/include -- cbits/directory.c cbits/rawSystem.c cbits/unicode.c /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Compat/Unicode.hs Distribution/Compat/Directory.hs Distribution/Compat/Exception.hs Distribution/Compat/Map.hs Distribution/Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Compat/TempFile.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Simple/Program.hs Distribution/Simple/Utils.hs Distribution/System.hs Distribution/Verbosity.hs Distribution/Version.hs Language/Haskell/Extension.hs System/FilePath.hs System/FilePath/Posix.hs System/FilePath/Windows.hs Trace/Hpc/Mix.hs Trace/Hpc/Tix.hs Trace/Hpc/Util.hs <<ghc: 36490248 bytes, 5 GCs, 130248/130248 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.01 elapsed), 0.22 MUT (4.47 elapsed), 0.06 GC (0.43 elapsed) :ghc>> make all /usr/local/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi gcc: unrecognized option '-no-cpp-precomp'
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: section difference relocatable subtraction expression, "_s2tx_0_alt" minus "_s2tx_info" using a symbol at the end of section will not produce an assembly time constant
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = _s2tx_0_alt - _s2tx_info
Someone has to dig into the .s file and figure out what is wrong. Also, you could try debugging a crashing binary using the instructions in http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes I doubt there's an easy way around this, someone really needs to get their hands dirty. Cheers, Simon
I've compiled GCC 4.01 from Apple's source code: http://www.opensource.apple.com/darwinsource/10.5/ However that does not include the linker. The linker used on 10.5 is actually from the ld64 project. Which looks to be a complete rewrite of ld from the cctools project. The ld64 source is available from the site linked above and can be easily compiled for debug. That said, the ld from cctools is still available on 10.5 and has the path /usr/bin/ld_classic. I'm currently swamped with work but have been slowly debugging ld64 to see why it fails to initialize a data member which results in a NULL pointer dereference. Still, the only thing I have of interest is a backtrace. Which isn't enough to tell me if the problem is due to a bug in ld64 or malformed input files. Although I'd argue all crashes are bugs and ld64 should be providing an error message on malformed input. #0 0x000222ac in ObjectFile::Section::getBaseAddress (this=0x0) at ObjectFile.h:182 182 uint64_t getBaseAddress() { return fBaseAddress; } (gdb) bt #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 (gdb) up 10 #10 0x0002113c in main (argc=465, argv=0xbffefb88) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:3568 3568 ld.link(); On Nov 15, 2007 1:56 AM, Chris Kuklewicz <haskell@list.mightyreason.com> wrote:
So I decided to try and route around the ld/collect2 problems with ghc-6.8.1 not working on powerpc OS X 10.5
OS X 10.5 (Leopard) uses XCode 3.0 which has a gcc-4.0 toolchain.
So I try to get another gcc & binutils from macports. This failed. All of gcc40 gcc41 gcc42 and gcc43 failed to compile successfully with macports.
So I switched to trying fink, which offers gcc-4.2.2 and this did compile and install. Hooray.
Unfortunately, using ghc-6.6.1 (from when I ran OS 10.4 Tiger) with gcc-4.2.2 does not work when compiling ghc-6.8.1 (at least on this platform).
------------------------------------------------------------------------ == make boot -r; in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1 /compiler ------------------------------------------------------------------------ ../utils/mkdirhier/mkdirhier stage1 for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn vectorise specialise simplCore stranal stgSyn simplStg codeGen main profiling parser cprAnalysis ndpFlatten iface cmm nativeGen; do \ ../utils/mkdirhier/mkdirhier stage1/$i; \ done Creating stage1/ghc_boot_platform.h... Done. ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl /bin/sh: line 1: 59384 Illegal instruction ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl make[1]: *** [primop-tag.hs-incl] Error 132 make[1]: *** Deleting file `primop-tag.hs-incl' make: *** [stage1] Error 1
Running "../utils/genprimopcode/genprimopcode --primop-tag" produces "Illegal instruction"
There were other odd messages during the make,such as in this early output:
------------------------------------------------------------------------ == make boot -r; in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1 /compat ------------------------------------------------------------------------ ../utils/mkdependC/mkdependC -f .depend -I. -Iinclude -I../includes -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=1 -I../libraries/base/cbits -I../libraries/base/include -- cbits/directory.c cbits/rawSystem.c cbits/unicode.c /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Compat/Unicode.hs Distribution/Compat/Directory.hs Distribution/Compat/Exception.hs Distribution/Compat/Map.hs Distribution/Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Compat/TempFile.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Simple/Program.hs Distribution/Simple/Utils.hs Distribution/System.hs Distribution/Verbosity.hs Distribution/Version.hs Language/Haskell/Extension.hs System/FilePath.hs System/FilePath/Posix.hs System/FilePath/Windows.hs Trace/Hpc/Mix.hs Trace/Hpc/Tix.hs Trace/Hpc/Util.hs <<ghc: 36490248 bytes, 5 GCs, 130248/130248 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.01 elapsed), 0.22 MUT (4.47 elapsed), 0.06 GC (0.43 elapsed) :ghc>> make all /usr/local/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi gcc: unrecognized option '-no-cpp-precomp'
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0:
section difference relocatable subtraction expression, "_s2tx_0_alt"
minus "_s2tx_info" using a symbol at the end of section will not produce an assembly time constant
/var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0:
use a symbol with a constant value created with an assignment
instead of the expression, L_const_sym = _s2tx_0_alt - _s2tx_info
The '-no-cpp-precomp' and 'section difference ...' and 'use a symbol ...' messages repeat often.
I looked at trac, and can only find the closed ticket http://hackage.haskell.org/trac/ghc/ticket/1427 relating to gcc-4.2 issues.
Does anyone have suggestions? hints? bad jokes?
-- Chris K _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- -Corey O'Connor
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 <mach-o/ppc/reloc.h> 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.
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 On Nov 15, 2007, at 11:15 AM, Chris Kuklewicz wrote:
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 <mach-o/ppc/reloc.h> 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. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
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 = {<text variable, no debug info>} 0x12b3784 <stg_returnToStackTop> (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
(gdb) disassemble Dump of assembler code for function stg_ap_p_fast: 0x012ba9b0 <stg_ap_p_fast+0>: andi. r31,r14,3 And Immediate (to get the two least significant bits of r14) 0x012ba9b4 <stg_ap_p_fast+4>: cmpwi r31,1 Equiv. to cmpi 0,0,r31,1 Compare Immediate 0x012ba9b8 <stg_ap_p_fast+8>: beq- 0x12ba9e0 <stg_ap_p_fast+48> Branch if equal (not taken, obviously, since the the next instructions are the fatal ones) 0x012ba9bc <stg_ap_p_fast+12>: li r31,-4 Load Immediate (I believe -4 is the opposite bit pattern to 3) 0x012ba9c0 <stg_ap_p_fast+16>: and r14,r14,r31 AND (to clear the two least significant bits of r14) 0x012ba9c4 <stg_ap_p_fast+20>: lwz r31,0(r14) Load Word and Zero 0x012ba9c8 <stg_ap_p_fast+24>: lha r31,-4(r31) [ The error was for the above operation: Load Halfword Algebraic destination general purpose register r31 source -4 displaced r31 ] 0x012ba9cc <stg_ap_p_fast+28>: rlwinm r31,r31,2,0,29 0x012ba9d0 <stg_ap_p_fast+32>: addis r31,r31,313 0x012ba9d4 <stg_ap_p_fast+36>: lwz r31,-28940(r31) 0x012ba9d8 <stg_ap_p_fast+40>: mtctr r31 0x012ba9dc <stg_ap_p_fast+44>: bctr 0x012ba9e0 <stg_ap_p_fast+48>: addi r22,r22,0 0x012ba9e4 <stg_ap_p_fast+52>: lwz r31,-1(r14) 0x012ba9e8 <stg_ap_p_fast+56>: mtctr r31 0x012ba9ec <stg_ap_p_fast+60>: bctr 0x012ba9f0 <stg_ap_p_fast+64>: addi r22,r22,-8 0x012ba9f4 <stg_ap_p_fast+68>: stw r15,4(r22) 0x012ba9f8 <stg_ap_p_fast+72>: b 0x12b666c <stg_ap_p_info> 0x012ba9fc <stg_ap_p_fast+76>: lwz r31,0(r14) 0x012baa00 <stg_ap_p_fast+80>: lha r31,-10(r31) 0x012baa04 <stg_ap_p_fast+84>: cmplwi r31,0 0x012baa08 <stg_ap_p_fast+88>: bgt- 0x12baa88 <stg_ap_p_fast+216> 0x012baa0c <stg_ap_p_fast+92>: li r3,0 0x012baa10 <stg_ap_p_fast+96>: li r4,2441 0x012baa14 <stg_ap_p_fast+100>: bl 0x1287c80 <_assertFail> 0x012baa18 <stg_ap_p_fast+104>: cmpwi r31,1 0x012baa1c <stg_ap_p_fast+108>: beq- 0x12baac8 <stg_ap_p_fast+280> 0x012baa20 <stg_ap_p_fast+112>: addi r22,r22,-8 0x012baa24 <stg_ap_p_fast+116>: stw r15,4(r22) 0x012baa28 <stg_ap_p_fast+120>: cmplwi r31,4 0x012baa2c <stg_ap_p_fast+124>: blt- 0x12baa8c <stg_ap_p_fast+220> 0x012baa30 <stg_ap_p_fast+128>: li r30,16 0x012baa34 <stg_ap_p_fast+132>: add r25,r25,r30 0x012baa38 <stg_ap_p_fast+136>: cmplw r25,r26 0x012baa3c <stg_ap_p_fast+140>: bgt- 0x12baa94 <stg_ap_p_fast+228> 0x012baa40 <stg_ap_p_fast+144>: addi r29,r25,4 0x012baa44 <stg_ap_p_fast+148>: subf r30,r30,r29 0x012baa48 <stg_ap_p_fast+152>: lis r29,298 0x012baa4c <stg_ap_p_fast+156>: ori r29,r29,60928 0x012baa50 <stg_ap_p_fast+160>: stw r29,0(r30) 0x012baa54 <stg_ap_p_fast+164>: addi r31,r31,-1 0x012baa58 <stg_ap_p_fast+168>: sth r31,4(r30) 0x012baa5c <stg_ap_p_fast+172>: stw r14,8(r30) 0x012baa60 <stg_ap_p_fast+176>: li r31,1 0x012baa64 <stg_ap_p_fast+180>: sth r31,6(r30) 0x012baa68 <stg_ap_p_fast+184>: li r31,0 0x012baa6c <stg_ap_p_fast+188>: cmplwi r31,1 0x012baa70 <stg_ap_p_fast+192>: blt- 0x12baaa8 <stg_ap_p_fast+248> 0x012baa74 <stg_ap_p_fast+196>: mr r14,r30 0x012baa78 <stg_ap_p_fast+200>: addi r22,r22,8 0x012baa7c <stg_ap_p_fast+204>: lwz r31,0(r22) 0x012baa80 <stg_ap_p_fast+208>: mtctr r31 0x012baa84 <stg_ap_p_fast+212>: bctr 0x012baa88 <stg_ap_p_fast+216>: b 0x12baa18 <stg_ap_p_fast+104> 0x012baa8c <stg_ap_p_fast+220>: add r14,r14,r31 0x012baa90 <stg_ap_p_fast+224>: b 0x12baa30 <stg_ap_p_fast+128> 0x012baa94 <stg_ap_p_fast+228>: stw r30,112(r27) 0x012baa98 <stg_ap_p_fast+232>: lis r31,299 0x012baa9c <stg_ap_p_fast+236>: ori r31,r31,26220 0x012baaa0 <stg_ap_p_fast+240>: stw r31,0(r22) 0x012baaa4 <stg_ap_p_fast+244>: b 0x12af8ac <__stg_gc_enter_1> 0x012baaa8 <stg_ap_p_fast+248>: addi r29,r31,1 0x012baaac <stg_ap_p_fast+252>: rlwinm r29,r29,2,0,29 0x012baab0 <stg_ap_p_fast+256>: lwzx r29,r22,r29 0x012baab4 <stg_ap_p_fast+260>: addi r28,r30,12 0x012baab8 <stg_ap_p_fast+264>: rlwinm r23,r31,2,0,29 0x012baabc <stg_ap_p_fast+268>: stwx r29,r28,r23 0x012baac0 <stg_ap_p_fast+272>: addi r31,r31,1 0x012baac4 <stg_ap_p_fast+276>: b 0x12baa6c <stg_ap_p_fast+188> 0x012baac8 <stg_ap_p_fast+280>: addi r22,r22,0 0x012baacc <stg_ap_p_fast+284>: addi r14,r14,1 0x012baad0 <stg_ap_p_fast+288>: li r31,-4 0x012baad4 <stg_ap_p_fast+292>: and r31,r14,r31 0x012baad8 <stg_ap_p_fast+296>: lwz r31,0(r31) 0x012baadc <stg_ap_p_fast+300>: mtctr r31 0x012baae0 <stg_ap_p_fast+304>: bctr 0x012baae4 <stg_ap_p_fast+308>: b 0x12baae4 <stg_ap_p_fast+308> 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' <repeats 16 times>, "\b", '\0' <repeats 22 times> }, 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' <repeats 23 times>, "\002" }, lock = { __sig = 1297437784, __opaque = '\0' <repeats 16 times>, "\b", '\0' <repeats 22 times> }, 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.
Chris Kuklewicz wrote:
(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
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
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
haskell@list.mightyreason.com wrote:
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.
I bet it would be easier to find a smaller program that crashes. Start from "hello world", or try the programs in testsuite/tests/ghc-regress/codeGen. Cheers, Simon
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
participants (5)
-
Chris Kuklewicz -
Corey O'Connor -
Deborah Goldsmith -
haskell＠list.mightyreason.com
-
Simon Marlow