#4417: Quasiquoting without bloating
---------------------------------+------------------------------------------
Reporter: rrnewton | Owner:
Type: feature request | Status: new
Priority: high | Milestone:
Component: Compiler | Version: 6.13
Keywords: executable size | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by batterseapower):
OK, well I had a crack at this over the weekend, but didn't get it done
within my time budget. Maybe someone else can pick up the baton.
I will attach a totally broken partial implementation of the feature.
Notes:
* I use the constructor attribute annotated with a *priority* to get
some control over the initialisation order
- hs_init is given a constructor attribute with a low priority 1000,
so it is run before all the module initialisers
- Priority 1500 is given to an initialisation function that does the
first half of hs_add_root, setting up a cap and stack for the initalisers
to run in
- Priority 2000 is used for all generated module initialisers, which
initialise only themselves (and NOT their dependencies)
- Priority 2500 is given to a function that does the last half of
hs_add_root to clean up after module initialisation
* A destructor attribute is used to ensure that hs_exit is called at
shutdown
So far so good, except that:
* OS X GCC 4.2.1 is not recent enough to support constructor priorities
(Cygwin GCC 4.3.4 does support them though) - not sure what to do here
* I got totally bogged down in DriverPipeline.hs getting the _stubs.o
object linked in to the corresponding .o. (I generate the constructor
attributes for a module's init functions in the stub file). Linking them
together into another .o with ld is necessary to ensure that the module
initialisers are called if any of the module's exports are referenced.
* hs_init needs to know the command line arguments, which aren't
available to the initialiser functions in the normal way. I wrote some
code to get them using the Windows API, but had to resort to a horrible
hack for other platforms.
That is basically where the patch is. Because the driver pipeline is
broken I haven't been able to give the initialisation strategy any serious
testing. In particular, I'm worried that things might go wrong if the RTS
assumes that modules are initialised in dependency order.
I think the treatment of foreign export stubs should be rethought in the
light of this requirement: we should always generate the stub object in a
temporary directory and just ld them together with the .o from the Haskell
source to generate the final object. This is actually independently useful
as e.g. external Haskell building tools don't have to worry about linking
in stub object files themselves.
I do not grok the GHC top level enough to take this further without some
serious extra time investment in reading the code.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4417#comment:5>
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
