|
Unix Programming - Studying Cases - Case Study: GCC
Case Study: GCC
GCC, the GNU C compiler used on most modern Unixes, is perhaps
an even better example of engineering for transparency. GCC is
organized as a sequence of processing stages knit together by a
driver program. The stages are: preprocessor, parser, code
generator, assembler, and linker.
Each of the first three stages takes in a readable textual
format and emits a readable textual format (the assembler has to emit
and the linker to accept binary formats, pretty much by definition).
With various command-line options of the
gcc(1)
driver, you can see not just the results after C preprocessing, after
assembly generation, and after object code generation — but you
can also monitor the results of many intermediate steps in parsing and
code generation.
|
This is exactly the structure of cc, the first (PDP-11) C
compiler.
|
|
| --
Ken Thompson
|
|
There are many benefits of this organization. One that is
particularly important for GCC is regression
testing.[60] Because most
of the various intermediate formats are textual, deviations from
expected results in a regression test are easily spotted and analyzed
using simple textual diff operations on the intermediate results;
there is no need for specialist dump-analysis tools that may well
harbor their own bugs, and in any case would represent an additional
maintenance burden.
The design pattern to extract from this example is that the
driver program has monitoring switches that merely (but sufficiently)
expose the textual data flows among the components. As with
fetchmail's -v option,
these options are not afterthoughts; they are designed in for
discoverability.
[an error occurred while processing this directive]
|
