This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Merge cpplib and front end hashtables, part 1
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Merge cpplib and front end hashtables, part 1
- From: Daniel Berlin <dan at www dot cgsoftware dot com>
- Date: Wed, 16 May 2001 10:14:35 -0400 (EDT)
- cc: Neil Booth <neil at daikokuya dot demon dot co dot uk>, <gcc-patches at gcc dot gnu dot org>, Zack Weinberg <zackw at Stanford dot EDU>
On Tue, 15 May 2001, Stan Shebs wrote:
> Neil Booth wrote:
> >
> > This is a first step, of three or four, towards merging cpplib's
> > hashtables with those of the C-family front ends, which will result in
> > blowing away most if not all of cpphash.c.
>
> Just a couple days ago on this list, the subject came up of letting
> GDB expand macros in expressions, and one of the assumptions for that
> project is that cpplib could be linked into GDB. I know this was an
> original goal of cpplib, but it hasn't been brought up much lately,
> and I'm wondering if this is still plausible, or if performance demands
> intertwining still more closely with cc1* and abandoning the GDB goal.
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.
We are not a compiler, remember, and we only handle *expressions*.
So the only part of expanding macros we need is taking a macro, and
replacing it with it's expansion. The rest of CPPLIB, in it's entirety,
is, well, useless to us.
IMHO, anyway.
So if performance demands or whatever cause it to become harder for gdb to
use cpplib as a whole, i don't see it as a loss.
However, it would be nice to be able to hook into macro expansion easier.
>
> Stan
>