From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18092 invoked by alias); 19 Mar 2002 00:03:20 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18008 invoked from network); 19 Mar 2002 00:03:19 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 19 Mar 2002 00:03:19 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 811855E9DE; Mon, 18 Mar 2002 19:03:17 -0500 (EST) To: Neil Booth Cc: gdb-patches@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: C/C++ preprocessor macro support for GDB References: <20020317062306.CC96D5E9DE@zwingli.cygnus.com> <20020318183339.GB19897@daikokuya.demon.co.uk> From: Jim Blandy Date: Mon, 18 Mar 2002 16:03:00 -0000 In-Reply-To: <20020318183339.GB19897@daikokuya.demon.co.uk> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00330.txt.bz2 Yes, yes. And I'm sure there are even basic preprocessor tokenization bugs, memory allocation bugs, wrote-=-when-he-meant-== bugs, etc. If I say, "I believe it would be better if it used libcpp" a third or fourth time, would that help? Should I put it in my .sig? Or should I just give up? :) Maybe people just can't believe that, having written my own macro expander, I could bear to see it replaced by someone else's code. But I *like* libcpp's code. What I've seen I found quite legible. Please believe me, macroexp.c is utterly disposable. It was written to be disposed of --- that's why macroexp.h is so short: to make it easy to see macroexp.c's relationship to the rest of the code, to make it easy to replace. What I do not want to do is block GDB's having even the most basic macro support on integrating a 11kloc library from a different repository, perhaps negotiating interface changes, etc. Simply because one is worried that desireable, important cleanups won't happen after a change doesn't mean that GDB is better off without the change at all. Neil Booth writes: > Jim Blandy wrote:- > > > > > The following patch adds support for C/C++ preprocessor macros to GDB. > > It's tentative: > > > > - There are no ChangeLog entries. > > - It's not broken up into relatively independent changes. > > - There's no documentation. > > - There are no tests. > > - There are some unimplemented features. > > > > Jim, > > I've looked over your patch a little more, and I don't think your macro > expander works, because it doesn't mark individual tokens. A "disabled > macro" stack is *not* enough by itself to implement ISO C macro expansion > semantics. You need to attach information to individual tokens as well. > I've not tried it, but I'd bet that > > #define A(x) x A(A)(1) > > expands to "1" with your code, whereas the correct expansion is "A(1)". > Implementing this properly is a PITA, more so with a text-based expander > like yours. It would be very hard to get the same (correct) semantics as > cpplib in corner cases with a text-based expander (2.95 has outstanding > bugs in this area). > > In addition, as you note #, ## and the various variadic macro semantics > and GCC extensions have not been implemented, I think a lot of work lies > ahead in this implementation. IMO using cpplib will be a lot less effort, > even after what you've already accomplished. > > Neil.