Christian Maeder wrote:
Rod Evans schrieb:
If this solves your problem ghc has a problem with object splitting
under some solaris linkers
Are you talking about the size issue we're presently discussing, or
another issue in which the Solaris linkers fail you? We'd be happy to
work with you directly to investigate things.
I'm only talking about this size issue. The size problem occurs already
in PrimOps.o (that is created from C-- sources "PrimOps.cmm").
Object splitting created the original file Utils__90.o with the size
problem.
http://www.opensolaris.org/jive/thread.jspa?threadID=32325&tstart=0
(I don't now yet if the original Utils.o has a size problem, too.)
I suppose creating object files from plain C should not result in object
files with a size problem.
Simon, do you have any idea why PrimOps.o has this problem (although
only for a picky new linker)?
Thanks for the pointer. 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.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
