From: Tom Tromey <tromey@redhat.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sourceware.org
Subject: Re: [RFC/RFA] add struct parse_context to all command functions
Date: Wed, 22 Oct 2008 18:54:00 -0000 [thread overview]
Message-ID: <m33aio4g67.fsf@fleche.redhat.com> (raw)
In-Reply-To: <200810221802.m9MI27P1024024@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Wed\, 22 Oct 2008 20\:02\:07 +0200 \(CEST\)")
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
next prev parent reply other threads:[~2008-10-22 18:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 14:05 Joel Brobecker
2008-10-09 16:13 ` Tom Tromey
2008-10-09 22:20 ` Joel Brobecker
2008-10-20 16:16 ` Joel Brobecker
2008-10-20 19:03 ` Thiago Jung Bauermann
2008-10-21 0:47 ` Daniel Jacobowitz
2008-10-21 18:06 ` Ulrich Weigand
2008-10-21 18:18 ` Daniel Jacobowitz
2008-10-22 1:40 ` Joel Brobecker
2008-10-22 20:15 ` Tom Tromey
2008-10-22 20:36 ` Joel Brobecker
2008-10-21 1:22 ` Tom Tromey
2008-10-21 7:07 ` Joel Brobecker
2008-10-21 18:12 ` Ulrich Weigand
2008-10-21 18:58 ` Tom Tromey
2008-10-21 19:33 ` Tom Tromey
2008-10-22 18:03 ` Ulrich Weigand
2008-10-22 18:54 ` Tom Tromey [this message]
2008-10-22 22:24 ` Ulrich Weigand
2008-10-23 1:02 ` Tom Tromey
2008-10-23 19:50 ` Ulrich Weigand
2008-10-23 21:29 ` Tom Tromey
2008-10-24 13:01 ` Ulrich Weigand
2008-10-25 16:05 ` Tom Tromey
2008-10-27 17:07 ` Tom Tromey
2008-10-28 16:27 ` Ulrich Weigand
2008-10-28 18:17 ` Tom Tromey
2008-10-28 20:00 ` Ulrich Weigand
2008-10-25 16:25 ` Joel Brobecker
2008-10-25 16:46 ` Tom Tromey
2008-10-26 15:19 ` Joel Brobecker
2008-10-21 18:05 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m33aio4g67.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox