From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13933 invoked by alias); 29 Mar 2002 21:17:52 -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 13909 invoked from network); 29 Mar 2002 21:17:50 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 29 Mar 2002 21:17:50 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 86D765EA11; Fri, 29 Mar 2002 16:17:49 -0500 (EST) To: Neil Booth Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: preprocessor macro support (should actually work now) References: <20020328070504.24F455EA11@zwingli.cygnus.com> <20020329100102.GA1261@daikokuya.demon.co.uk> From: Jim Blandy Date: Fri, 29 Mar 2002 13:17:00 -0000 In-Reply-To: <20020329100102.GA1261@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/msg00608.txt.bz2 Neil Booth writes: > I've done a bit more research into examples of when token marking is > needed when expanding macros. There are a few in the CPP testsuite; > here is one (I got this by disabling the feature in CPP and seeing > what broke): > > #define M(x) 2 + M(x) > #define N(a) M(a) > N (N (9)) > > The correct expansion is > > 2 + M(2 + M(9)) > > I expect your code (though I've not tested it!) will get: > > 2 + M(2 + 2 + M(9)) Yes indeedy: (gdb) show macro M Defined at /rigel/jimb/gdb/macros/play/macros4.c:4 included at /rigel/jimb/gdb/macros/play/macros4.c:0 #define M(x) 2 + M(x) (gdb) show macro N Defined at /rigel/jimb/gdb/macros/play/macros4.c:5 included at /rigel/jimb/gdb/macros/play/macros4.c:0 #define N(a) M(a) (gdb) macro expand N (N (9)) expands to: 2 + M(2 + 2 + M(9)) (gdb) (That `included at macros4.c:0' stuff is a GCC bug I think Daniel B's working on.) For spectators: libcpp represents the stream of source code it's expanding as an array of token structures, not a simple array of characters. When it sees some macro named X expand to a sequence that includes the identifier token X, it sets a flag on that token indicating that it should never be expanded as a macro invocation. As the example shows, this flag may need to remain set long after the original invocation of the macro named X has been processed. I don't see any easy way to get this effect with a string-based expander, like the one in my patch. I didn't really understand all the logistics that got brought up regarding moving libcpp into its own directory in the repository, to make it easier to share with gdb. But the sooner that happens, the sooner we can replace my macro expander with one that works better.