Re: [RFC/RFA] add struct parse_context to all command functions

["Ulrich Weigand" <uweigand@de.ibm.com>]

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