From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6088 invoked by alias); 18 Mar 2002 07:29:29 -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 5961 invoked from network); 18 Mar 2002 07:29:21 -0000 Received: from unknown (HELO monkey.daikokuya.demon.co.uk) (158.152.184.26) by sources.redhat.com with SMTP; 18 Mar 2002 07:29:21 -0000 Received: from neil by monkey.daikokuya.demon.co.uk with local (Exim 3.35 #1 (Debian)) id 16mra1-0003ub-00; Mon, 18 Mar 2002 07:29:17 +0000 Date: Sun, 17 Mar 2002 23:29:00 -0000 From: Neil Booth To: Jim Blandy Cc: gdb-patches@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: C/C++ preprocessor macro support for GDB Message-ID: <20020318072916.GB14970@daikokuya.demon.co.uk> References: <20020317062306.CC96D5E9DE@zwingli.cygnus.com> <20020317101938.GA2636@daikokuya.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-SW-Source: 2002-03/txt/msg00299.txt.bz2 Jim Blandy wrote:- > (gdb) break *ADDRESS if CONDITION > > This sets a conditional breakpoint at the address computed by > evaluating the expression ADDRESS, whose condition is CONDITION. > ADDRESS needs to be evaluated in the current scope --- the currently > selected frame and its PC --- but CONDITION needs to be evaluated in > the scope in force at the *breakpoint's* address. So you can't just > take the whole command and smoosh it through an expander all at > once: ADDRESS and CONDITION might have totally different contexts, > as far as the preprocessor is concerned. I don't understand why this is hard. Just expand ADDRESS and CONDITION separately, no? I don't think an "if" in address counts as starting the condition, right? > This means you've got to decide if there's an `if' in the command > before you can macro-expand things. Obviously, an `if' in a string, > or as part of a larger identifier, doesn't count --- you really need > to work in terms of tokens. Why can't you just do a quick scan before expanding anything? What am I missing? > As far as I can tell, libcpp doesn't provide an analogous > token-by-token entry point. It has the ability to macro-expand an arbitrary text buffer; you just loop getting the tokens until CPP_EOF. > There's nothing too hard there. But I wanted to put together a > patch which actually worked, while disturbing the existing GDB code > as little as possible. And I think there's something unsatisfying > about the two-pass approach; parsers ought to be able to leave input > unconsumed if they want. It's a common enough idiom. Shouldn't > libcpp support it? I'm afraid I can't see a problem. Maybe a detailed example with an actual GDB command with an embedded C macro would help? > - GDB's macro data structures record all the macros that were ever > #defined in a compilation unit, and the line numbers at which they > were in force. Given a name and an #inclusion and a line number (or > in libcpp's terminology, a logical line number?), it can find the > #definition in scope at that point. Yes. I think I know what you're about to say. I went through this with Dan. > This is a bit different from libcpp's data structures, which only > record the macros currently in force as libcpp makes a pass through > the file's text. (At least, that's the impression I got.) Yes. > My macro expander is completely ignorant of the lookup table's > structure; you pass it a function and a data pointer that it uses > blindly for lookups. Here's the relevant typedef, and one of the > prototypes, from the expander's public interface: [...] I believe all you need is to put your text in a buffer, loop getting tokens (possibly from a parser) until CPP_EOF, and a callback that cpplib calls for each identifier to request its macro definition, if any. At present this callback does not exist, but can be easily added. cpplib would also need a "flush_nonbuiltin_macro_definitions" interface so that it doesn't endlessly consume more memory storing macro definitions, which you could call at the end of an expression. Neil.