From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30071 invoked by alias); 23 Jan 2006 15:27:09 -0000 Received: (qmail 30062 invoked by uid 22791); 23 Jan 2006 15:27:07 -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; Mon, 23 Jan 2006 15:27:06 +0000 Received: from diveadx (duck.specifix.com [64.220.152.99]) by duck.specifix.com (Postfix) with ESMTP id 08E6941E5; Mon, 23 Jan 2006 07:27:05 -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: Mon, 23 Jan 2006 15:27:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sourceware.org References: <200601031517.50309.fnf@specifix.com> <20060115184800.GA9948@nevyn.them.org> <8f2776cb0601152022w6985d911y101f8a7d964f83b6@mail.gmail.com> In-Reply-To: <8f2776cb0601152022w6985d911y101f8a7d964f83b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601231027.05302.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/msg00325.txt.bz2 On Sunday 15 January 2006 23:22, Jim Blandy wrote: > On 1/15/06, Daniel Jacobowitz wrote: > > Given the followups, I think this patch is OK. Jim, do you agree? > > I think we're going to end up coming back to it, but the patch is > definitely an improvement over the status quo, and doesn't interfere > with further improvements, so I think the patch is okay too. The patch doesn't work though if there is a current frame, from debugging a running process or examining a core file. This is because of the order for searching for the block: if (!block) block = get_selected_block (&expression_context_pc); if (!block) { struct symtab_and_line cursal = get_current_source_symtab_and_line (); if (cursal.symtab) block = BLOCKVECTOR_BLOCK (BLOCKVECTOR (cursal.symtab), STATIC_BLOCK); } So perhaps it would be better to fix this by allowing the user to specify the context directly, like when printing a variable of type foo instead of just the type foo: (gdb) ptype 'char.c'::afoo type = char (gdb) ptype 'int.c'::afoo type = int (gdb) ptype 'main.c'::afoo type = long int So something like the following, which currently produces an error: (gdb) ptype 'main.c'::foo Cannot look up value of a typedef -Fred