From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19728 invoked by alias); 4 Jan 2006 02:46:49 -0000 Received: (qmail 19719 invoked by uid 22791); 4 Jan 2006 02:46:49 -0000 X-Spam-Check-By: sourceware.org Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO duck.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 02:46:46 +0000 Received: from diveadx (duck.specifix.com [64.220.152.99]) by duck.specifix.com (Postfix) with ESMTP id 2FF93FA8C; Tue, 3 Jan 2006 18:46:40 -0800 (PST) From: Fred Fish Reply-To: fnf@specifix.com To: Jim Blandy Subject: Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units Date: Wed, 04 Jan 2006 02:46:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sourceware.org, fnf@specifix.com References: <200601031517.50309.fnf@specifix.com> <8f2776cb0601031515m8ef145x5e23aa5f80644428@mail.gmail.com> In-Reply-To: <8f2776cb0601031515m8ef145x5e23aa5f80644428@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601032147.14083.fnf@specifix.com> 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-01/txt/msg00022.txt.bz2 On Tuesday 03 January 2006 18:15, Jim Blandy wrote: > The test looks good; please commit that. OK. > I have some questions about the patch, though. > get_current_source_symtab_and_line is a user-interface thing, and I'm > uncomfortable calling it from one of our fundamental lookup functions. There is a static pointer to the current source symtab in source.c, and only functions in that file have direct access to it. All the rest of gdb seems to use one of the accessor functions exported from source.c: get_current_source_symtab_and_line set_current_source_symtab_and_line clear_current_source_symtab_and_line > Why isn't the right block being passed to lookup_symbol in the first > place? ptype_command() calls parse_expression() with the name of the type as the only argument parse_expression() calls parse_exp_1() with zero as the block parse_exp_1() simply calls parse_exp_in_context(), passing on zero. parse_exp_in_context() sees that block is zero and tries to find expression_context_block by calling get_selected_block(), but since the target isn't running, that returns zero, which gets saved in expression_context_block. parse_exp_context() then calls the C parser, which calls the lexer, which calls lookup_symbol() with the current value of expression_context_block, which is zero. -Fred