From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25899 invoked by alias); 20 Feb 2006 16:23:29 -0000 Received: (qmail 25891 invoked by uid 22791); 20 Feb 2006 16:23:29 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 20 Feb 2006 16:23:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBDom-0004bm-1m; Mon, 20 Feb 2006 11:23:20 -0500 Date: Mon, 20 Feb 2006 16:23:00 -0000 From: Daniel Jacobowitz To: Fred Fish Cc: Jim Blandy , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units Message-ID: <20060220162320.GF16058@nevyn.them.org> Mail-Followup-To: Fred Fish , Jim Blandy , gdb-patches@sourceware.org References: <200601031517.50309.fnf@specifix.com> <20060214141056.GB21812@nevyn.them.org> <200602161916.00761.fnf@diveadx.com> <200602201046.08713.fnf@specifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602201046.08713.fnf@specifix.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00364.txt.bz2 On Mon, Feb 20, 2006 at 10:46:08AM -0500, Fred Fish wrote: > OK, here is a patch. I'm not entirely happy with it but I'm not familiar > enough with parser generator input and output to see any obviously > better way. > > The basic problem is that it's easy to handle 'file'::variable. The > existing code for this is: > > block : block COLONCOLON name > { struct symbol *tem > = lookup_symbol (copy_name ($3), $1, > VAR_DOMAIN, (int *) NULL, > (struct symtab **) NULL); > > What happens is that "name" is handled by a lookup_symbol call with > no context block specified, and then the above calls lookup_symbol > again with the context specified by $1 (block). > > But for types, the parser generator input is: > > type : ptype > | block COLONCOLON ptype > { $$ = $3; } > > Setting expression_context_block for the duration of parsing the > input expression was the only obvious way I saw to work around > not being able to call lookup_symbol again, with the right block. > > I tried setting expression_context_block on the lexer code when it > returned BLOCKNAME or FILENAME and that broke some other stuff. > > Any suggestions on better ways to handle this would be great. Yuck. In general futzing with global variables in a parser is bad news. And here's another good hint that this isn't happening in the right place: type : ptype + | block COLONCOLON ptype + { $$ = $3; } but ptype : typebase, and typebase : INT_KEYWORD. So this will allow "ptype var.c:int". I don't think that's a great idea (especially since we won't use the debug info to look up "int" in that case anyway so we still won't detect a mismatch). The problem you're having is that the lexer looks up symbols without knowing their context. I think you're going to have some fragile failure modes with things that are types in one file and not in another, which it would be nice to support if we could. The fact that we try to differentiate between these two in the lexer is a bit problematic. One easy way to improve here would be to just look up the symbol again. But that still relies on the lexer having decided this was a typename. I'm not sure what to suggest. Really this parser needs some more thorough love and care. -- Daniel Jacobowitz CodeSourcery