Duncan
It sounds good to me (although I am not a well-informed witness).
Can I urge you to transfer (and edited version of) your email into the
Commentary, so that others can find out how things work?
You and I also discussed (at FITA) the desirability of writing an overview of
how dynamic linking in GHC works, including
- links to good descriptions of the base OS arrangements (eg windows
dlls, Unix sos)
- a description of how we use this stuff in GHC (eg pic code, -dynamic,
etc)
Linking is much more complicated than it seems!
thanks for progressing this stuff
Simon
| -----Original Message-----
| From: [email protected] [mailto:[email protected]] On
Behalf Of
| Duncan Coutts
| Sent: 14 May 2009 00:25
| To: GHC CVS list
| Subject: Where 'main' lives and where it should live
|
| linking enthusiasts,
|
| To better support shared libraries I would like to move where the 'main'
| symbol is defined (in the linker symbol sense, not the C code).
|
| The C code for 'main' is in rts/Main.c. Currently this gets compiled to
| rts/Main.$(way_)o and linked into the rts library.
|
| The fact that 'main' is compiled into the rts library is actually a
| little odd when you think about it. Normally we think of 'main' as being
| the top of a call tree, rather than something in one of the lower layers
| like the rts.
|
| More specifically we might wonder how it works when we use a 'main'
| defined by the user in a .c file. It works by relying on the behaviour
| of static linkers which allows one symbol to shadow another of the same
| name. So as long as the static linker sees the user's main before it
| sees the main in the libHSrts.a library then it's all good. In fact it
| relies on slightly more than that. It also relies on the static linker
| not pulling in the 'main' from libHSrts.a if in fact it's not needed
| (due to it previously finding the user's 'main'). It's a good thing that
| it doesn't pull in 'main' from libHSrts.a because the code for 'main'
| refers to a symbol corresponding to the Haskell Main.main function (or
| at least something that points to it).
|
| This subtle scheme does not work with dynamic libraries. While ELF
| dynamic linking mirrors static linking in that duplicate symbols are
| allowed and the first is picked, we cannot discard the 'main' that lives
| in libHSrts.so and that one now has unresolved symbols when we're not
| using a Haskell Main.main.
|
| So I propose that we do not keep 'main' in the rts library. Instead we
| should keep Main.o as a separate .o file that sits along side the
| installed rts library and whenever we use a Haskell main, then we just
| link in Main.o. Obviously when we link using -no-hs-main then we don't.
|
| I suggest that for consistency and sanity we do this for all ways, not
| just when using dynamic libraries. Currently there is code in GHC to do
| this just for Windows when using dynamic libraries (because windows DLLs
| have even more severe problems with the existing scheme).
|
| I currently have this approach working, though it involves having a copy
| of Main for each 'way', ie Main.thr_o, Main.debug_thr_o etc. GHC picks
| the right one during linking. Something like this is needed because the
| current Main.c uses conditional compilation on the 'way'. The downside
| of what I've got it doing at the moment is that the symbol dependencies
| between Main.o and the rts depend on the way and that precludes
| switching the rts way at runtime (via LD_PRELOAD) which is a rather
| handy feature to have. Instead I suggest that the code in Main.c remain
| in the rts but under a different name, and that we compile a single
| 'main' function that calls into the new entry point. That would give us
| a consistent ABI dependency between the startup code and the rts. So it
| may make sense to rename Main.c to something like Init.c and make a new
| Main.c that's literally only a couple lines long, calling into the entry
| point defined in Init.c. Then we only compile and install Main.o once,
| not per way.
|
| Sound like a plan? I'll try it tomorrow.
|
| Duncan
|
| _______________________________________________
| Cvs-ghc mailing list
| [email protected]
| http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
