This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [Ada] Enhance type printing for arrays with variable-sized elements


> 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
> 
> gdb/ChangeLog:
> 
> 	* ada-typeprint.c (print_array_type): Do not describe arrays as
> 	packed when they embed dynamic elements.
> 
> gdb/testsuite/ChangeLog:
> 
> 	* 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,
I think.

Other than that, the patch itself looks pretty good to me.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]