Re: gengtype future directions

[Geoffrey Keating <geoffk at apple dot com>]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature