This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/3] Initial support for variant parts
On Tue, Feb 20, 2018 at 12:06:11PM -0700, Tom Tromey wrote:
> This adds some initial support for variant parts to gdbtypes.h. A
> variant part is represented as a union. The union has a flag
> indicating that it has a discriminant, and information about the
> discriminant is attached using the dynamic property system.
>
> 2018-02-19 Tom Tromey <tom@tromey.com>
>
> * value.h (value_union_variant): Declare.
> * valops.c (value_union_variant): New function.
> * gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): New macro.
> (struct discriminant_info): New.
> (enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: New
> enumerator.
> (struct main_type) <flag_discriminated_union>: New field.
OK for me. Some questions and notes below, for discussion, more than
a request to change...
> +struct discriminant_info
> +{
> + /* * The index of the discriminant field. If -1, then this union
> + must have just a single field. */
> +
> + int discriminant_index;
> +
> + /* * The index of the default branch of the union. If -1, then
> + there is no default branch. */
> +
> + int default_index;
> +
> + /* * The discriminant values corresponding to each branch. This has
> + a number of entries equal to the number of fields in this union.
> + If discriminant_index is not -1, then that entry in this array is
> + not used. If default_index is not -1, then that entry in this
> + array is not used. */
> +
> + ULONGEST discriminants[1];
It took me a while to answer to myself why "discriminants[default_index]"
is unused if default_index != 1. IIUC, that's because the default branch
can apply to multiple indices, right?
A small note: We (probably the Ada maintainers) will have to extend
your current approach to discriminant handling because a given branch
may be apply to multiple values of a given discriminant.
Another note for the future: Discriminants in Ada can be any discrete
type (integers, signed or unsigned, enum, etc) or even an access type
(the equivalent of a pointer in C). Thinking of the future, I think we
would change the ULONGEST here into an array of char * containing the
target-side representation of the dicriminant. Or would you suggest
something different?
This would also help with ...
> + if (info->default_index == -1)
> + error (_("Could not find variant corresponding to discriminant %s"),
> + pulongest (discriminant));
... printing the value of the discriminant whose branch we couldn't
find in the error message above.
--
Joel