[GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h
GHC
ghc-devs at haskell.org
Tue Apr 3 19:23:30 UTC 2018
#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
More information about the ghc-tickets
mailing list