This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Merge cpplib and front end hashtables, part 1


Mark Mitchell <mark@codesourcery.com> writes:

> >>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:
> 
>     Daniel> It would be less work to write a good macro expander then
>     Daniel> it would to do the above.
>  
> GDB is beyond my purview.  None-the-less, I'll horn in with my
> opinion. :-)
> 
> One of the biggest mistakes that we can make with free software is to
> build the same thing over again.  Perhaps the largest practical
> advantage of free software vis a vis proprietary software is that free
> software developers can share their efforts easily, whereas
> proprietary vendors are often forced to reinvent the wheel.  
> 
> It is, in my opinion, a mistake for the GNU Project to have two C
> macro expanders.  Even it is more work in the short-term, there will
> be significant long-term wins from investing whatever effort is
> necessary in GDB and/or cpplib to make the two work together. 

This is the problem. I just don't see that.  The macro expansion part
of cpplib is less than 10% of all the cpplib code.

(On a weird aside, strangely, i have another C99 compliant preprocessor in front
of me, and their macro expansion is only 14 bytes less code than
ours.  Weird, no?)

We gain nothing else but macro expansion.  We don't do include files,
we don't need it to parse actual files for us, we can't do multiline
statements anyway (other limitations will get in the way), etc.

It would be like integrating an entire compiler so you can get
algebraic simplification or something.

It's so much overkill, it's not even funny, IMHO.

> 
> I would urge the GDB people postpone macro expansion, cool though it
> would be, if there isn't sufficiently much effort available to
> incorporate cpplib.

That's fine.  The debug reader work is already done, and keeping the
macros in the symbol table is still the way to go. It's just a matter
of where we actually perform the lookup and evaluation that is at
issue here.  

It'll just do nothing until someone cpplibify's c-exp.y

> 
> My two cents,
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

-- 
"I saw a bank that said "24 Hour Banking", but I don't have that
much time.
"-Steven Wright


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]