Ticket #1421 (closed bug: fixed)
elf object code problem exposed when linking under i386 Solaris 10
|Reported by:||maeder@…||Owned by:|
|Type of failure:||Difficulty:||Unknown|
|Test Case:||Blocked By:|
The object code generated for i386 Solaris 10 can not be linked with newer solaris linkers.
It works for:
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.486
and probably for all other linkers before 5.11-1.554 (and gnu linkers)
It fails for:
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.555
and probably for 5.11-1.554 and newer ones, too
The failure message is as follows:
Linking hello ... ld: fatal: symbol `GHC_ZCCReturnable_static_info' in file /export/home/sparvu/ghcnew/lib/ghc-6.6.1/libHSrts.a(PrimOps.o): section  .text: size 8464: symbol (address 0x2110, size 4) lies outside of containing section ld: fatal: File processing errors. No output written to hello collect2: ld returned 1 exit status
In fact elfdump(1) (for ld 5.10-1.486) displays:
Section Header: sh_name: .text sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] sh_size: 0x2110 sh_type: [ SHT_PROGBITS ] sh_offset: 0x34 sh_entsize: 0 sh_link: 0 sh_info: 0
Symbol Table Section: .symtab index value size type bind oth ver shndx name [...]  0x0000210c 0x00000004 OBJT GLOB D 0 .text GHC_ZCCCallable_static_info  0x00002110 0x00000004 OBJT GLOB D 0 .text GHC_ZCCReturnable_static_info
The same size problem is described under: http://www.opensolaris.org/jive/thread.jspa?threadID=32325&tstart=0 for the splitted object file Utils__90.o.
I've found a possible related link here: http://hackage.haskell.org/trac/ghc/changeset/8920
Rod.Evans at sun.com wrote:
The checking we've added was under: 6488141 ld(1) should detect attempt to reference 0-length .bss section integrated in Nevada snv_54. It stemmed from our compiler development giving ld(1) some bad files that resulted in us core dumping. An ld(1) that reported: ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.554 would have been the first to contain the above "bug fix". I don't believe this change has found its way back to a Solaris 10 port yet.
We'd be happy to work with you directly to investigate things.
simonmarhaskell at gmail.com wrote:
I'm guessing the bogus .size information is a result of the reorganisation of the .s file that we do before assembling it: gcc inserts .size directives, we move things around in the .s, and at the end it the .size directives aren't right any more.
The only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it.
I can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives.