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
- From: Daniel Berlin <dan at dberlin dot org>
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Cc: Jim Blandy <jimb at redhat dot com>, <gdb-patches at sources dot redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Mar 2002 03:05:59 -0500 (EST)
- Subject: Re: RFC: C/C++ preprocessor macro support for GDB
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