Merge cpplib and front end hashtables, part 1

Daniel Berlin dan@cgsoftware.com
Wed May 16 11:53:00 GMT 2001


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

> Daniel Berlin wrote:-
> 
> > Personally, I could care less either way.
> > cpplib as it stands right now is too hard to integrate into GDB, mainly
> > because expanding macros in gdb means we want a text string back, not
> > tokens.
> 
> Surely gdb's C expression parser acts on tokens? 

Sure. 

>  If so, why isn't it
> easy to just pass the whole expression to cpplib and parse the token
> stream back, like the front-ends would (though you only have to handle
> expressions this way I imagine).  

Because it's a serious pain in the ass to do. 
At the point we go to do the macro expansion, we have already
converted the expression into a bunch of opcodes that get evaluated by
gdb in a stack machine.  The parser has done it's work, and thus, we
don't have a parser to hand it back to.  The language dependent code
is done, in other words.
So what has to happen is that we have to evaluate the result of the
expansion from scratch, which means evaluating it as if it was an
input string.

> I can't see why text is better to
> you than tokens.
Because we have no parser to hand it back to, with context and all, at
this point. 
In other words, macro expansion ain't done in the parser, it's called
by the evaluator.  It would be a serious hunk of work to move it back
into the parser, and then make the parser use cpplib internally.

It would be less work to write a good macro expander then it would to do
the above.
 
> 
> Neil.

-- 
"I was walking down the street and saw a sign on a post.  It
said:  "Lost -- $50.  If found, just keep it."
"-Steven Wright



More information about the Gcc-patches mailing list