From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20886 invoked by alias); 18 Mar 2002 08:06:05 -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 20758 invoked from network); 18 Mar 2002 08:06:02 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 18 Mar 2002 08:06:02 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g2I85xm21790; Mon, 18 Mar 2002 03:05:59 -0500 Date: Mon, 18 Mar 2002 00:06:00 -0000 From: Daniel Berlin To: Neil Booth cc: Jim Blandy , , Subject: Re: RFC: C/C++ preprocessor macro support for GDB In-Reply-To: <20020318072916.GB14970@daikokuya.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-03/txt/msg00300.txt.bz2 On Mon, 18 Mar 2002, Neil Booth wrote: > 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. Yes, and I had actually implemented libcpp as gdb's macro preprocessor a while ago to test the macro info output. You just need a lookup callback to lookup in some outside structure. That, and a bunch the stupid little niggly defines/typedefs from gcc's autoconf generated *.h files Other than that, it's just not hard. I *really* don't see why Jim went to all the trouble, since it would probably have taken less than half a week to add the necessary changes to libcpp. Even if he didn't want to use libcpp, due to interface, ucpp would fit well here too and is smaller/has no memory issues. UCPP was "designed to be fast, with low memory consumption, and reusable as a lexer in other projects". You'd end up just replacing the get_macro function. Heck, it even has sample code on using it as an integrated lexer. Though personally, i'd still use libcpp. --Dan