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

[Daniel Berlin <dan@dberlin.org>]

On Mon, 18 Mar 2002, Neil Booth wrote:

> Jim Blandy wrote:-
> 
> >         (gdb) break *ADDRESS if CONDITION
> > 
> >   This sets a conditional breakpoint at the address computed by
> >   evaluating the expression ADDRESS, whose condition is CONDITION.
> >   ADDRESS needs to be evaluated in the current scope --- the currently
> >   selected frame and its PC --- but CONDITION needs to be evaluated in
> >   the scope in force at the *breakpoint's* address.  So you can't just
> >   take the whole command and smoosh it through an expander all at
> >   once: ADDRESS and CONDITION might have totally different contexts,
> >   as far as the preprocessor is concerned.
> 
> I don't understand why this is hard.  Just expand ADDRESS and CONDITION
> separately, no?  I don't think an "if" in address counts as starting the
> condition, right?
> 
> >   This means you've got to decide if there's an `if' in the command
> >   before you can macro-expand things.  Obviously, an `if' in a string,
> >   or as part of a larger identifier, doesn't count --- you really need
> >   to work in terms of tokens.
>  
> Why can't you just do a quick scan before expanding anything?  What am I
> missing?
> 
> >   As far as I can tell, libcpp doesn't provide an analogous
> >   token-by-token entry point.
> 
> It has the ability to macro-expand an arbitrary text buffer; you just
> loop getting the tokens until CPP_EOF.
> 
> >   There's nothing too hard there.  But I wanted to put together a
> >   patch which actually worked, while disturbing the existing GDB code
> >   as little as possible.  And I think there's something unsatisfying
> >   about the two-pass approach; parsers ought to be able to leave input
> >   unconsumed if they want.  It's a common enough idiom.  Shouldn't
> >   libcpp support it?
> 
> I'm afraid I can't see a problem.  Maybe a detailed example with an
> actual GDB command with an embedded C macro would help?
>  
> > - GDB's macro data structures record all the macros that were ever
> >   #defined in a compilation unit, and the line numbers at which they
> >   were in force.  Given a name and an #inclusion and a line number (or
> >   in libcpp's terminology, a logical line number?), it can find the
> >   #definition in scope at that point.
> 
> Yes.  I think I know what you're about to say.  I went through this with
> Dan.

Yes, and I had actually implemented libcpp as gdb's macro preprocessor a 
while ago to test the macro info output.
You just need a lookup callback to lookup in some outside structure. 
That, and a bunch the stupid little niggly defines/typedefs from gcc's 
autoconf generated *.h files
Other than that, it's just not hard.
I *really* don't see why Jim went to all the trouble, since it would 
probably have taken less than half a week to add the necessary 
changes to libcpp.


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".
You'd end up just replacing the get_macro function.
Heck, it even has sample code on using it as an integrated lexer.
Though personally, i'd still use libcpp.


--Dan