On 26/03/2007, at 3:12 PM, Zack Weinberg wrote:
Most of gengtype's hardwired kludges exist because it does not do preprocessing, and therefore my recommendation is that we work toward a state where gengtype can use libcpp to do that (we already have a preprocessor library, let's use it :) If libcpp is too slow for this application that should be dealt with by improvements to libcpp.
I considered doing something like this during the original design of gengtype, and rejected it.
I don't see that it's necessarily possible to make libcpp as fast as gengtype. libcpp has to do much more work than gengtype does because libcpp processes every token whereas gengtype spends most of its time scanning source looking for a few keywords and does not need to understand every weird thing that someone might do (like putting a GTY marker inside a string). gengtype does not even need to examine every character in its input source files (although I don't know if flex is smart enough to do this).
Although it might seem like a benefit that gengtype could deduce which types are relevant for GC by itself, the existing GTY(()) markers actually have a significant documentation use: they inform users of the structure that the structure is supposed to be allocated in GC-managed memory. So I would recommend keeping these whether they are necessary or not, and if possible verifying that they are consistent.
I doubt the remaining benefit of doing this (making some parts of the design of gengtype conceptually simpler) exceeds the cost of doing the work plus the cost of maintaining the larger gengtype front-end plus the cost of maintaining the libcpp changes needed to bend it to this fairly unnatural purpose.
If I was writing something like gengtype for any project other than GCC, I would do it differently: I would write a tool which read DWARF from .o files instead of reading source code directly. This approach would allow use of any part of C or even C++, and would be even faster than the existing gengtype. However, GCC needs to be more portable than this would allow.
smime.p7s
Description: S/MIME cryptographic signature
