This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: C/C++ preprocessor macro support for GDB
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.