From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9869 invoked by alias); 22 Oct 2008 22:24:12 -0000 Received: (qmail 9860 invoked by uid 22791); 22 Oct 2008 22:24:12 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 22:23:21 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id m9MMNIvN048594 for ; Wed, 22 Oct 2008 22:23:18 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9MMNID32015392 for ; Thu, 23 Oct 2008 00:23:18 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9MMNHL5017001 for ; Thu, 23 Oct 2008 00:23:18 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m9MMNH99016998; Thu, 23 Oct 2008 00:23:17 +0200 Message-Id: <200810222223.m9MMNH99016998@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Oct 2008 00:23:17 +0200 Subject: Re: [RFC/RFA] add struct parse_context to all command functions To: tromey@redhat.com Date: Wed, 22 Oct 2008 22:24:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at Oct 22, 2008 12:51:12 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00561.txt.bz2 Tom Tromey wrote: > 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. Ah, I'd forgotten about that thread. I'll have a look at the above patch. > 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 ;) Sure, that's fine with me :-) > 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? I'd prefer a copy, just like the other routines. > I'll fix this by fixing print_formatted as you suggested. OK. > 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. OK, I'm fine with this. However, this means that we'll really have to construct the option struct on the fly, we cannot have a global struct hold pre-initialized pointers to current_language etc. (But if you use a get_default_print_options () routine that constructs an option struct, the routine can just fill in the current values.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com