#1421: elf object code problem exposed when linking under i386 Solaris 10
-----------------------------+----------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: Runtime System | Version: 6.6.1
Severity: normal | Keywords:
Difficulty: Unknown | Os: Solaris
Testcase: | Architecture: x86
-----------------------------+----------------------------------------------
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1421>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
