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

[Jim Blandy <jimb at redhat dot com>]

Yes, yes.  And I'm sure there are even basic preprocessor tokenization
bugs, memory allocation bugs, wrote-=-when-he-meant-== bugs, etc.

If I say, "I believe it would be better if it used libcpp" a third or
fourth time, would that help?  Should I put it in my .sig?  Or should
I just give up?  :)

Maybe people just can't believe that, having written my own macro
expander, I could bear to see it replaced by someone else's code.  But
I *like* libcpp's code.  What I've seen I found quite legible.  Please
believe me, macroexp.c is utterly disposable.  It was written to be
disposed of --- that's why macroexp.h is so short: to make it easy to
see macroexp.c's relationship to the rest of the code, to make it easy
to replace.

What I do not want to do is block GDB's having even the most basic
macro support on integrating a 11kloc library from a different
repository, perhaps negotiating interface changes, etc.  Simply
because one is worried that desireable, important cleanups won't
happen after a change doesn't mean that GDB is better off without the
change at all.


Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Jim Blandy wrote:-
> 
> > 
> > The following patch adds support for C/C++ preprocessor macros to GDB.
> > It's tentative:
> > 
> > - There are no ChangeLog entries.
> > - It's not broken up into relatively independent changes.
> > - There's no documentation.
> > - There are no tests.
> > - There are some unimplemented features.
> > 
> 
> Jim,
> 
> I've looked over your patch a little more, and I don't think your macro
> expander works, because it doesn't mark individual tokens.  A "disabled
> macro" stack is *not* enough by itself to implement ISO C macro expansion
> semantics.  You need to attach information to individual tokens as well.
> I've not tried it, but I'd bet that
> 
> #define A(x) x A(A)(1)
> 
> expands to "1" with your code, whereas the correct expansion is "A(1)".
> Implementing this properly is a PITA, more so with a text-based expander
> like yours.  It would be very hard to get the same (correct) semantics as
> cpplib in corner cases with a text-based expander (2.95 has outstanding
> bugs in this area).
> 
> In addition, as you note #, ## and the various variadic macro semantics
> and GCC extensions have not been implemented, I think a lot of work lies
> ahead in this implementation.  IMO using cpplib will be a lot less effort,
> even after what you've already accomplished.
> 
> Neil.