Re: RFC: C/C++ preprocessor macro support for GDB

[Neil Booth <neil@daikokuya.demon.co.uk>]

Daniel Berlin wrote:-

> Even if he didn't want to use libcpp, due to interface, ucpp would fit 
> well here too and is smaller/has no memory issues. UCPP was "designed to 
> be fast, with low memory consumption, and reusable as a lexer in other 
> projects".

ucpp is quite nice, and implemented quite differently to cpplib.
When Thomas wrote it, he was correct that it used a lot less memory than
the pre-3.0 cpplib.  If you recall, however, there was a silly bug of
mine that led to memory not being freed, and macro expansion tended to
consume ever more memory.

This was fixed in 3.0, and I made further improvements to memory
consumption in 3.1.  I think it's fair to say that cpplib is now equal
to ucpp, and in high-stress macro expansion outperforms it significantly
memory-wise.  [And uses less memory than all previous cpp implementations
in GCC.]  I think cpplib is also faster than ucpp, though that's not
important for GDB.  Zack and I hope to squeeze out more memory efficiency
sometime in 3.2 by shrinking the size of cpp_token from 16 / 24 bytes
to 12 / 16 bytes [32bit/64bit].  Since most of cpplib's memory use is
storing macro expansions in tokenized form, this should help reduce
memory consumption by at least another 10% I'd estimate.

ucpp does not expand some macros the same way as cpplib.  cpplib's
expansion algorithm matches what was _intended_ by the subcommitte that
standardized macro expansion, although it is debatable whether their
use of English in the standardese is clear enough.  [I was kindly sent
a psuedo-code algorithm that they agreed to in 1989 by Dave Prosser,
who took part in the standardization work.  It was described in terms of
macro hide sets.  Oddly enough, the only commercial preprocessor that
implements it perfectly appears to be SCO's 8-) cpplib instead uses
a disabled macro stack with token marking, which is considerably more
efficient, but achieves an identical result].  ucpp does not implement
GCC's macro extensions, of course.  We should have GCC and GDB agree
perfectly on macro expansion, otherwise there is little point.

Neil.