From c57d9ab39c887454a365a3e552a7fa6006a773dd Mon Sep 17 00:00:00 2001 From: chak Date: Fri, 24 Aug 2001 06:17:56 +0000 Subject: [PATCH] [project @ 2001-08-24 06:17:56 by chak] * Added a brief outline of the handling of command line options * Revised Reuben's explanation re -no-hs-main according to our email exchange --- ghc/docs/comm/index.html | 6 +- ghc/docs/comm/the-beast/driver.html | 105 ++++++++++++++++++++++++++++------- 2 files changed, 90 insertions(+), 21 deletions(-) diff --git a/ghc/docs/comm/index.html b/ghc/docs/comm/index.html index 5f2c020..ca3b283 100644 --- a/ghc/docs/comm/index.html +++ b/ghc/docs/comm/index.html @@ -6,7 +6,7 @@ -

The Glasgow Haskell Compiler (GHC) Commentary [v0.2]

+

The Glasgow Haskell Compiler (GHC) Commentary [v0.3]

Manuel M. T. Chakravarty
+ Simon Marlow
+ Reuben Thomas
 

This document started as a collection of notes describing what -Last modified: Wed Aug 22 16:47:29 GMT Daylight Time 2001 +Last modified: Fri Aug 24 16:17:11 EST 2001 diff --git a/ghc/docs/comm/the-beast/driver.html b/ghc/docs/comm/the-beast/driver.html index c7770ed..3895f28 100644 --- a/ghc/docs/comm/the-beast/driver.html +++ b/ghc/docs/comm/the-beast/driver.html @@ -12,50 +12,117 @@ interaction of all the other pieces that make up GHC. It supersedes the Evil Driver (ED), which was a Perl script that served the same purpose and was in use until version 4.08.1 of GHC. Simon Marlow - eventually slayed the ED and instated the GD. + eventually slayed the ED and instated the GD. The GD is usually called + the Compilation Manager these days.

The GD has been substantially extended for GHCi, i.e., the interactive variant of GHC that integrates the compiler with a (meta-circular) - interpreter since version 5.00. + interpreter since version 5.00. Most of the driver is located in the + directory + fptools/ghc/compiler/main/.

+

Command Line Options

+

+ GHC's many flavours of command line options make the code interpreting + them rather involved. The following provides a brief overview of the + processing of these options. Since the addition of the interactive + front-end to GHC, there are two kinds of options: static + options and dynamic options. The former can only be set + when the system is invoked, whereas the latter can be altered in the + course of an interactive session. A brief explanation on the difference + between these options and related matters is at the start of the module + CmdLineOpts. + The same module defines the enumeration DynFlag, which + contains all dynamic flags. Moreover, there is the labelled record + DynFlags that collects all the flag-related information + that is passed by the compilation manager to the compiler proper, + hsc, whenever a compilation is triggered. If you like to + find out whether an option is static, use the predicate + isStaticHscFlag in the same module. +

+ The second module that contains a lot of code related to the management + of flags is DriverFlags.hs. + In particular, the module contains two association lists that map the + textual representation of the various flags to a data structure that + tells the driver how to parse the flag (e.g., whether it has any + arguments) and provides its internal representation. All static flags + are contained in static_flags. A whole range of + -f flags can be negated by adding a -f-no- + prefix. These flags are contained in the association list + fFlags. +

+ The driver uses a nasty hack based on IORefs that permits + the rest of the compiler to access static flags as CAFs; i.e., there is + a family of toplevel variable definitions in + CmdLineOpts, + below the literate section heading Static options, each of which + contains the value of one static option. This is essentially realised + via global variables (in the sense of C-style, updatable, global + variables) defined via an evil pre-processor macro named + GLOBAL_VAR, which is defined in a particularly ugly corner + of GHC, namely the C header file + HsVersions.h. +

Linking the RTS and libHSstd

Since the RTS and HSstd refer to each other, there is a Cunning Hack to avoid putting them each on the command-line twice or thrice (aside: try asking for `plaice and chips thrice' in a - fish and chip shop; bet you only get two lots), namely to add + fish and chip shop; bet you only get two lots). The hack involves + adding the symbols that the RTS needs from libHSstd, such as PrelWeak_runFinalizzerBatch_closure and - __init_Prelude to the link line with the - -u flag. The standard library appears before the - RTS on the link line (why? might it be better the other way - around? [SPJ]), and these options cause the corresponding - symbols to be picked up even if they haven't been already, so - that when the RTS is also scanned, they are resolved. This + __init_Prelude, to the link line with the + -u flag. The standard library appears before the + RTS on the link line, and these options cause the corresponding + symbols to be picked up even so the linked might not have seen them + being used as the RTS appears later on the link line. As a result, + when the RTS is also scanned, these symbols are already resolved. This avoids the linker having to read the standard library and RTS multiple times.

- This does, however, lead to a complication. Normal Haskell - programs do not have a main function, so this is - supplied by the RTS. It calls startupHaskell, which + This does, however, leads to a complication. Normal Haskell + programs do not have a main() function, so this is + supplied by the RTS (in the file + Main.c). + It calls startupHaskell, which itself calls __init_PrelMain, which is therefore, since it occurs in the standard library, one of the symbols - passed to the linker. However, when the main - function is provided by the programmer (e.g. when there is no - main module, but a C module instead), + passed to the linker using the -u option. This is fine + for standalone Haskell programs, but as soon as the Haskell code is only + used as part of a program implemented in a foreign language, the + main() function of that foreign language should be used + instead of that of the Haskell runtime. In this case, the previously + described arrangement unfortunately fails as __init_PrelMain had better not be linked in, because it tries to call __init_Main, which won't - exist. This case is coped with by the -no-hs-main - flag, although in some versions of the compiler (e.g. 5.00.2) it - didn't work. + exist. In other words, the RTS's main() refers to + __init_PrelMain which in turn refers to + __init_Main. Although the RTS's main() + might not be linked in if the program provides its own, the driver + will normally force __init_PrelMain to be linked in anyway, + using -u, because it's a back-reference from the + RTS to HSstd. This case is coped with by the -no-hs-main + flag, which suppresses passing the corresonding -u option + to the linker -- although in some versions of the compiler (e.g., 5.00.2) + it didn't work. In addition, the driver arranges that the C program + providing the main() that we want to use appears in the + link line after the RTS. Therefore, the RTS's main is never used and + without the -u the label __init_PrelMain + will not be linked.

-Last modified: Wed Aug 22 17:01:33 GMT Daylight Time 2001 +Last modified: Fri Aug 24 16:16:10 EST 2001 -- 1.7.10.4