elf object code problem exposed when linking under i386 Solaris 10
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 [1] .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[1]: 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
and
Symbol Table Section: .symtab
index value size type bind oth ver shndx name
[...]
[200] 0x0000210c 0x00000004 OBJT GLOB D 0 .text GHC_ZCCCallable_static_info
[201] 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.
and
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.
Trac metadata
Trac field | Value |
---|---|
Version | 6.6.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Runtime System |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |