From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21427 invoked by alias); 22 Oct 2008 18:54:47 -0000 Received: (qmail 21394 invoked by uid 22791); 22 Oct 2008 18:54:46 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 18:53:55 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m9MIpGCK008101; Wed, 22 Oct 2008 14:51:16 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m9MIpE6U030633; Wed, 22 Oct 2008 14:51:15 -0400 Received: from opsy.redhat.com (vpn-12-160.rdu.redhat.com [10.11.12.160]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m9MIpD2x005941; Wed, 22 Oct 2008 14:51:14 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 1E6D8378701; Wed, 22 Oct 2008 12:51:13 -0600 (MDT) To: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sourceware.org Subject: Re: [RFC/RFA] add struct parse_context to all command functions References: <200810221802.m9MI27P1024024@d12av02.megacenter.de.ibm.com> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Wed, 22 Oct 2008 18:54:00 -0000 In-Reply-To: <200810221802.m9MI27P1024024@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Wed\, 22 Oct 2008 20\:02\:07 +0200 \(CEST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00548.txt.bz2 Ulrich> However, (some of) the places where you now have to reference Ulrich> members of user_print_options seems to indicate either that Ulrich> something is really weird (why should evaluate_subexp_standard Ulrich> *evaluate* an expression differently depending on Ulrich> "objectprint" ??), or that some routines maybe need to get Ulrich> print options passed as arguments (print_formatted? address Ulrich> printing? the breakpoint print routines?). Yeah, there's some weird stuff. In most cases I did not want to change behavior, so I just added a reference to the global. For evaluate_subexp_standard, there was a patch recently in this area: http://sourceware.org/ml/gdb-patches/2008-08/msg00525.html AFAIK this has not been reviewed. For breakpoint print routines, I don't know. I consider this part of the patch a kind of technicality -- only needed because I chose to remove the globals entirely, which I only did to ensure that I caught all uses in the call hierarchy I really cared about. This sort of thing can easily be addressed later, if necessary. The reason I'm not sure it is necessary is that it seems to me that the user would really want breakpoint-printing to use the current globals. So, capturing the state somewhere would not be correct. At that point... well, I'd rather have Joel solve this problem ;) Ulrich> In fact, I'm wondering if it wouldn't be nicer to also have something Ulrich> like a get_default_print_options function instead of refering to the Ulrich> user_print_options global in the top-level printing routines ... No problem. Do you want it to make a copy? Or just return a pointer to the global? Ulrich> However, with your code it would appear "inspect" is now a no-op: Whoops. Well, I did say it was untested :-) I'll fix this by fixing print_formatted as you suggested. Ulrich> There's still two globals used in various places throughout the Ulrich> print routines: current_language and current_gdbarch. Ideally, Ulrich> these should be replaced by passing arguments as well ... I'm Ulrich> not sure if the value_print_options structure is the correct Ulrich> place to put language and gdbarch pointer, though. Do you have Ulrich> and opinions how to handle those? I don't really mind putting these into that structure. In the context of this call hierarchy, these are immutable arguments to a particular call, modifying that call's behavior. For me that is enough to qualify them. But, we could take other approaches. We could pass in a structure that contains a struct value_print_options and a struct something_else. FWIW I'd like to keep just a single "options" argument -- many of these functions already have too many arguments. Tom