#12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): I've developed a possible fix for this ticket, but I have some questions about the nature of GHC's runtime symbols. Depending on the answers, I'm afraid my fix will just push the problem to a different location, and not really be a fix at all. This ticket's description states that it's error-prone for a developer to keep GHC's runtime symbols in sync between the runtime system's C header files (*.h) and C source files (*.c). The goal is to remove the developer from having to decide if the runtime symbols are in sync, and have an algorithm perform that task instead. The runtime symbols naturally fall into mathematical sets: * Set "A": All runtime function symbols in `includes/Rts.h` (and its included headers). * Set "B": All runtime function symbols exported by the `rtsSyms[]` array in `rts/RtsSymbols.c`. It should be a simple matter of calculating the set difference `(A - B)` to discover what symbols aren't being exported. Unfortunately, it's not so simple. Set "A" has about 870 symbols, and set "B" about 560. This means roughly 310 symbols aren't being exported. These symbols appear to be legitimately intended to never be exported. We'll call this set "C": * Set "C": All runtime function symbols in `includes/Rts.h` intentionally **NOT** exported by the `rtsSyms[]` array in `rts/RtsSymbols.c`. Now the algorithm becomes `(A - B) - C`, which works. But there's a problem. The contents of sets "A" and "B" can be determined algorithmically. However, the contents of set "C" must be determined semantically - i.e. a developer must decide what symbols should and should not be in set "C". The goal of removing the developer from the decision-making process has not been met. Questions: * Should set "C" exist? As long as it does, a completely algorithmic solution will never be possible, because a developer will still be required to make a decision about the contents of set "C". In other words, the current problem of a developer forgetting to add a symbol to set "B" (the rtsSyms[] array in rts/RtsSymbols.c), is replaced by a new problem of a developer deciding what symbols belong in set "C". My fix would just shift the problem to new location (along with the addition of about 1000 lines of new code and documentation in GHC's code base). * The only fix I can think of is to eliminate set "C" by requiring any symbol appearing in set "A" to also appear in set "B". Is this feasible? Thanks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12891#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler