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

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

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.

>   This is a bit different from libcpp's data structures, which only
>   record the macros currently in force as libcpp makes a pass through
>   the file's text.  (At least, that's the impression I got.)

Yes.

>   My macro expander is completely ignorant of the lookup table's
>   structure; you pass it a function and a data pointer that it uses
>   blindly for lookups.  Here's the relevant typedef, and one of the
>   prototypes, from the expander's public interface:

[...]

I believe all you need is to put your text in a buffer, loop getting
tokens (possibly from a parser) until CPP_EOF, and a callback that
cpplib calls for each identifier to request its macro definition, if
any.  At present this callback does not exist, but can be easily added.

cpplib would also need a "flush_nonbuiltin_macro_definitions" interface so
that it doesn't endlessly consume more memory storing macro definitions,
which you could call at the end of an expression.

Neil.