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

Ulrich Weigand
2008-10-22T22:24:12Z

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