elf object code problem exposed when linking under i386 Solaris 10

[maeder@…]

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.

[maeder@…]

I've recompiled PrimOps?.cmm

../compiler/ghc-inplace -H16m -O -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint   -#include posix/Itimer.h  -c PrimOps.cmm -o PrimOps.o -keep-s-file -keep-raw-s-file 

The PrimOps?.o file is now different (I don't know why). Therefore I've included the elfdump of it (PrimOps.o.eldump)

[maeder@…]

after changed mangler

[maeder@…]

after changed mangler

[maeder@…]

Simon's guess did the trick!

I guess we should just eliminate the .size directives if the linker is going to be picky about them.  In ghc-asm.lprl you'll find

    $T_COPY_DIRVS   = '^\s*\.(globl|type|size|local)';

if you change it to

    $T_COPY_DIRVS   = '^\s*\.(globl|local)'; 

I'll attach my ghc-asm.lprl file

A working binary distribution (built using gcc-4.1.2) can be found under  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/versions/new-ghc-6.6.1-i386-unknown-solaris2.tar.bz2

[maeder@…]

fix for Solaris 11 linker