This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] [Ada] Enhance type printing for arrays with variable-sized elements
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pierre-Marie de Rodat <derodat at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 15 Sep 2015 09:06:11 -0700
- Subject: Re: [PATCH] [Ada] Enhance type printing for arrays with variable-sized elements
- Authentication-results: sourceware.org; auth=none
- References: <1442315486-4885-1-git-send-email-derodat at adacore dot com>
> Before this change, we would get the following GDB session:
> (gdb) ptype a
> type = array (1 .. 2) of foo.r_type <packed: 838-bit elements>
> This is wrong: "a" is not a packed array. This output comes from the
> fact that, because R_Type has a dynamic size (with a maximum), the
> compiler has to describe in the debugging information the size allocated
> for each array element (i.e. the stride, in DWARF parlance: see
> DW_AT_byte_stride). Ada type printing currently assumes that arrays
> with a stride are packed, hence the above output.
> In practice, GNAT never performs bit-packing for arrays that contain
> variable-sized elements. Leveraging this fact, this patch enhances type
> printing so that ptype does not pretend that arrays are packed when they
> have a stride and they contain dynamic elements. After this change, we
> get the following expected output:
> (gdb) ptype a
> type = array (1 .. 2) of foo.r_type
> * ada-typeprint.c (print_array_type): Do not describe arrays as
> packed when they embed dynamic elements.
> * gdb.ada/array_of_variable_length.exp: New testcase.
> * gdb.ada/array_of_variable_length/foo.adb: New file.
> * gdb.ada/array_of_variable_length/pck.adb: New file.
> * gdb.ada/array_of_variable_length/pck.ads: New file.
This looks like an easy improvement. Thanks, Pierre-Marie!
I'm curious - what happens if you do:
(gdb) print a
(gdb) ptype $
The concern is that $ refers to the resolved version of "A", and
that therefore we might lose the dynamic property. But I think it will
work in this case, because we do not resolve the array's element type
(each element of the actual array has to be resolved individually,
since the actual type changes from element to element).
It's worth extending your new testcase with the above scenario as well,
Other than that, the patch itself looks pretty good to me.