[Bug m3/27049] New: gdb crashes when printing variable of 2 dimensional dynamic array

[Bug m3/27049] New: gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

            Bug ID: 27049
           Summary: gdb crashes when printing variable of 2 dimensional
                    dynamic array
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: m3
          Assignee: unassigned at sourceware dot org
          Reporter: peter.mckinna at gmail dot com
  Target Milestone: ---

Created attachment 13036
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13036&action=edit
dwarf dump of executable

Trying to print a dynamic array of greater than one dimension fails in
gdb 10.1

See debug attempt here

(gdb) ptype refArr
type = INTEGER (*)[variable length][variable length]
(gdb) p refArr
$1 = (INTEGER (*)[variable length][variable length]) 0x555555580158
(gdb) p *refArr
$2 = {
value.c:1526: internal-error: CORE_ADDR value_address(const value*): Assertion
`PROP_CONST == TYPE_DATA_LOCATION_KIND (value_type (value))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

gdb and operating system info

GNU gdb (GDB) 10.1
This GDB was configured as "x86_64-pc-linux-gnu".
Linux Mars 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64
GNU/Linux

The program is a modula-3 program compiled with cm3 and generating llvm IR
The source code summary is
TYPE
  ArrType = ARRAY OF ARRAY OF INTEGER;
VAR
  arr : ArrType
BEGIN
  arr := NEW(ArrType,12,8);
END

A one dimensional dynamic array works. It did not work in gdb 8 but
has since been fixed.

It is difficult to build a testcase without installing cm3 and llvm
I have attached a summary of the dwarf from llvm-dwarfdump

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Can you still provide instructions for compiling a reproducer and reaching the
bug?  I'm willing to install the needed tools, but I'll need precise
instructions, because I've never dealt with Modula 3 before.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
Maybe just attaching a minimal reproducing executable with debuginfo,
with instructions for running it, would be good enough.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #3 from peter mckinna <peter.mckinna at gmail dot com> ---
HI,

  Thanks for the quick response. I was going to reply to simark that it's
quite difficult to
build a demo as I'm working on llvm debug generation and you would have to
build
llvm from source then apply a patch and then build cm3 from source. All of
which
is time consuming and tricky.

I can attach a minimal executable for running on Linux plus generated llvm
IR
and assembly output - total gziped size of about 2.2 M.

Hope that would suffice.

Regards Peter

On Sat, 12 Dec 2020 at 01:16, tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=27049
>
> Tom Tromey <tromey at sourceware dot org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |tromey at sourceware dot
> org
>
> --- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
> Maybe just attaching a minimal reproducing executable with debuginfo,
> with instructions for running it, would be good enough.
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #4 from peter mckinna <peter.mckinna at gmail dot com> ---
Created attachment 13046
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13046&action=edit
gzipped tar containing demo executable of bug plus source and assembly

I have added a test executable for running on Linux 64 bit machine
containing the source program and generated assemble .s and llvm IR .ll
files. An objdump of the exe should match the assembly file
and dwarfdump should verify the dwarf.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-12-12

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Ok, I am able to reproduce using your program.

So, here's the problematic variable and its type:

0x000000ac:   DW_TAG_variable
                DW_AT_name [DW_FORM_strp]       ("ref2dim")
                DW_AT_type [DW_FORM_ref4]       (0x000000c8 "RefDynArr2")
                DW_AT_decl_file [DW_FORM_data1]
("/home/peter/cm3/testsimple/gdbbug/src/Main.m3")
                DW_AT_decl_line [DW_FORM_data1] (1)
                DW_AT_location [DW_FORM_exprloc]        (DW_OP_addr 0x76010,
DW_OP_plus_uconst 0x290)
                DW_AT_linkage_name [DW_FORM_strp]       ("ref2dim")

0x000000c8:   DW_TAG_pointer_type
                DW_AT_type [DW_FORM_ref4]       (0x000000d1 "INTEGER[][]")
                DW_AT_name [DW_FORM_strp]       ("RefDynArr2")

0x000000d1:   DW_TAG_array_type
                DW_AT_data_location [DW_FORM_exprloc]  
(DW_OP_push_object_address, DW_OP_deref)
                DW_AT_type [DW_FORM_ref4]       (0x000000ea "INTEGER[]")

0x000000d9:     DW_TAG_subrange_type
                  DW_AT_type [DW_FORM_ref4]     (0x00000060 "INTEGER")
                  DW_AT_name [DW_FORM_strp]     ("DynArr2_rng")
                  DW_AT_lower_bound [DW_FORM_exprloc]   (DW_OP_lit0)
                  DW_AT_count [DW_FORM_exprloc] (DW_OP_push_object_address,
DW_OP_plus_uconst 0x8, DW_OP_deref)

0x000000e9:     NULL

GDB doesn't like that the data location dynamic property of the array type is
not a constant.  That code, including the assert, was added here:

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=9920b4348edb;hp=d5486c43728b4fa17c111a301c30a1e072eaec6a

What I don't understand is that according to DWARF (5), dynamic properties,
including DW_AT_data_location, are location expressions.  So I'm not sure why
this code expects the data location dynamic prop to be a constant.  So I'm not
sure what the original intention was...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
I think the problem is that resolve_dynamic_array_or_string
has this recursive call:

  if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
    elt_type = resolve_dynamic_array_or_string (ary_dim, addr_stack);


However, only resolve_dynamic_type_internal handles a dynamic
location.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 5de5bd5ae41..8bb8b4e95f2 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -2279,7 +2279,7 @@ resolve_dynamic_array_or_string (struct type *type,
   ary_dim = check_typedef (TYPE_TARGET_TYPE (elt_type));

   if (ary_dim != NULL && ary_dim->code () == TYPE_CODE_ARRAY)
-    elt_type = resolve_dynamic_array_or_string (ary_dim, addr_stack);
+    elt_type = resolve_dynamic_type_internal (ary_dim, addr_stack, 0);
   else
     elt_type = TYPE_TARGET_TYPE (type);

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
I'm not totally sure if that is correct, but it does prevent the crash
at least.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #9 from peter mckinna <peter.mckinna at gmail dot com> ---
Awesome. You're a genius. I will check it out as well as testing higher
order dimensioned arrays.
It sort of makes sense.

Thanks.

On Wed, 16 Dec 2020 at 05:24, tromey at sourceware dot org <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=27049
>
> --- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
> I'm not totally sure if that is correct, but it does prevent the crash
> at least.
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[andrew.burgess at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

Andrew Burgess <andrew.burgess at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew.burgess at embecosm dot com

--- Comment #10 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
I think Tom's fix makes sense.  The reason I don't think we've run into this
before is that the way the 2 dimensional array is being represented is not
similar to what we see in (say) Fortran.

To expand on the DWARF Simon posted, here's the same thing plus a little extra:

  <1><ac>: Abbrev Number: 2 (DW_TAG_variable)
     <ad>   DW_AT_name        : (indirect string, offset: 0x71): ref2dim
     <b1>   DW_AT_type        : <0xc8>
     <b5>   DW_AT_decl_file   : 1
     <b6>   DW_AT_decl_line   : 1
     <b7>   DW_AT_location    : 12 byte block: 3 10 60 7 0 0 0 0 0 23 90 5     
 (DW_OP_addr: 76010; DW_OP_plus_uconst:>
     <c4>   DW_AT_linkage_name: (indirect string, offset: 0x71): ref2dim
  <1><c8>: Abbrev Number: 7 (DW_TAG_pointer_type)
     <c9>   DW_AT_type        : <0xd1>
     <cd>   DW_AT_name        : (indirect string, offset: 0x85): RefDynArr2
  <1><d1>: Abbrev Number: 8 (DW_TAG_array_type)
     <d2>   DW_AT_data_location: 2 byte block: 97 6     
(DW_OP_push_object_address; DW_OP_deref)
     <d5>   DW_AT_type        : <0xea>
  <2><d9>: Abbrev Number: 9 (DW_TAG_subrange_type)
     <da>   DW_AT_type        : <0x60>
     <de>   DW_AT_name        : (indirect string, offset: 0x79): DynArr2_rng
     <e2>   DW_AT_lower_bound : 1 byte block: 30         (DW_OP_lit0)
     <e4>   DW_AT_count       : 4 byte block: 97 23 8 6 
  <2><e9>: Abbrev Number: 0
  <1><ea>: Abbrev Number: 8 (DW_TAG_array_type)
     <eb>   DW_AT_data_location: 2 byte block: 97 6     
(DW_OP_push_object_address; DW_OP_deref)
     <ee>   DW_AT_type        : <0x60>
  <2><f2>: Abbrev Number: 9 (DW_TAG_subrange_type)
     <f3>   DW_AT_type        : <0x60>
     <f7>   DW_AT_name        : (indirect string, offset: 0x5a): DynArr1_rng
     <fb>   DW_AT_lower_bound : 1 byte block: 30         (DW_OP_lit0)
     <fd>   DW_AT_count       : 4 byte block: 97 23 10 6 
  <2><102>: Abbrev Number: 0

The interesting thing here that I don't see from Fortran is that the 2
dimensions are represented as a DW_TAG_array_type that has a DW_AT_type that is
also a DW_TAG_array_type.  Each array_type has a single DW_TAG_subrange_type,
and each array has its own DW_AT_data_location.  I guess this allows for the
possibility that each dimension of the array might be stored at disjoint
locations in memory??

In Fortran we usually see a single DW_TAG_array_type with multiple
DW_TAG_subrange_type children (one per dimension).  The array will have a
DW_AT_data_location (so just one for the whole array).

However, inside GDB we do model multi-dimensional arrays as arrays of arrays,
this can be seen in dwarf/read.c:read_array_type.  The first DW_TAG_array_type
and DW_TAG_subrange_type create the first GDB ARRAY type object, and each
additional DW_TAG_subrange_type creates a new ARRAY type object which is the
TARGET_TYPE of the more outer array dimension.  What this means is that we
(previously) only expected to see DW_AT_data_location on the first GDB ARRAY
type object.  Each additional level of ARRAY type would not have a data
location (and so would use the location of its more outer array level).

I had a read through the DWARF spec for arrays and though the approach being
taken here is unusual (i.e. I don't see it discussed as a possible way to
represent multi-dimensional arrays in the spec) I don't see any reason why this
should be prohibited.  As such Tom's suggested change seems reasonable to me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[andrew.burgess at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #11 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
Created attachment 13059
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13059&action=edit
Test case.

I wrote a test for this issue (see attached).  And after writing this I
realised that Tom's proposed solution is not going to do what we'd want it to
do.

To explain, here we have the important bits from the DWARF representing our
array of arrays.  Then I have the memory contents, with addresses on the left,
and contents on the right.

-------------------------------------

($0) VARIABLE
=============
DW_AT_location: 0x1000
DW_AT_type: $1

($1) ARRAY
==========
subrange: lower_bound = 1, count = 4
DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
DW_AT_type: $2

($2) ARRAY
==========
subrange: lower_bound = 1, count = 4
DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
DW_AT_type: $3

($3) INTEGER
============
size: 4
signed: true

-------------------------------------

...
0x1000:   0x2000
...
0x2000:   0x3000
0x2004:   0x4000
...
0x3000:   0
0x3004:   1
0x3008:   2
0x300c:   3
...
0x4000:   0
0x4004:   1
0x4008:   2
0x400c:   3
...

-------------------------------------

The variable $0 is at address 0x1000.  At this address is a pointer to an array
of pointers.  Each of these pointers points to a separate dimension of the
array, one at address 0x3000 and one at 0x4000.  The complete array is NOT in
one contiguous block in memory.

I am representing the array this way as it is my assumption that this is the
only reason for giving each of the nested array types their own
DW_AT_data_location.


The problem we have is that currently inside GDB we have the variable ($0)
which has dynamic type.  When we want to use this variable we call
resolve_dynamic_type and pass in the address of the variable $0.

When we resolve the DW_AT_data_location for the outer array type ($1) we use
the address of the variable $0 as the value pushed when we execute
DW_OP_push_object_address.

Next we try to resolve the element type of the array.  This is the problem, an
array has a single element type.  But if you look at the above then each 2nd
rank array can have its own separate data location.  As we currently store the
resolved data location on the type then we can only support a single data
location for all elements.

What currently happens with Tom's patch is that when resolving the element type
we re-use the address of the variable $0 as the object address, each of the 2nd
rank array types then points to the same area of memory, in our example above
this would be the address 0x2000.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #12 from peter mckinna <peter.mckinna at gmail dot com> ---
The thing is - it works.

I don't know of any language that uses more than one dope vector to
describe a dynamic array
and that's where the data loc is stored. Imagine if there was one dope
vector per dimension.
Allocations would be a lot more inefficient and complex, not to mention
array access. Indirecting
though multiple vectors to calc the address of an element would be crazy.
So in practice, I think
there will always only ever be one allocation.

That said, it makes sense that the data loc belongs to the outermost
dimension array type.
It was trivial for my test to remove all the data loc tags for the inner
arrays and gdb still
worked. So I think one could safely ignore them if they exist. Dwarf is a
loose spec after all.

As an aside. It surprised me when I first saw the fortran Dwarf for a
multiple dim array and
it had all the subranges for the array as children. I couldn't find a
mention in the spec to
support that arrangement and it seemed to depend on the lexical ordering of
the subrange
as to which dimension it applied. I mean subrange does not have an
attribute saying it applies
to index x or whatever.

On Fri, 18 Dec 2020 at 04:30, andrew.burgess at embecosm dot com <
sourceware-bugzilla@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=27049
>
> --- Comment #11 from Andrew Burgess <andrew.burgess at embecosm dot com>
> ---
> Created attachment 13059
>   --> https://sourceware.org/bugzilla/attachment.cgi?id=13059&action=edit
> Test case.
>
> I wrote a test for this issue (see attached).  And after writing this I
> realised that Tom's proposed solution is not going to do what we'd want it
> to
> do.
>
> To explain, here we have the important bits from the DWARF representing our
> array of arrays.  Then I have the memory contents, with addresses on the
> left,
> and contents on the right.
>
> -------------------------------------
>
> ($0) VARIABLE
> =============
> DW_AT_location: 0x1000
> DW_AT_type: $1
>
> ($1) ARRAY
> ==========
> subrange: lower_bound = 1, count = 4
> DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
> DW_AT_type: $2
>
> ($2) ARRAY
> ==========
> subrange: lower_bound = 1, count = 4
> DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
> DW_AT_type: $3
>
> ($3) INTEGER
> ============
> size: 4
> signed: true
>
> -------------------------------------
>
> ...
> 0x1000:   0x2000
> ...
> 0x2000:   0x3000
> 0x2004:   0x4000
> ...
> 0x3000:   0
> 0x3004:   1
> 0x3008:   2
> 0x300c:   3
> ...
> 0x4000:   0
> 0x4004:   1
> 0x4008:   2
> 0x400c:   3
> ...
>
> -------------------------------------
>
> The variable $0 is at address 0x1000.  At this address is a pointer to an
> array
> of pointers.  Each of these pointers points to a separate dimension of the
> array, one at address 0x3000 and one at 0x4000.  The complete array is NOT
> in
> one contiguous block in memory.
>
> I am representing the array this way as it is my assumption that this is
> the
> only reason for giving each of the nested array types their own
> DW_AT_data_location.
>
>
> The problem we have is that currently inside GDB we have the variable ($0)
> which has dynamic type.  When we want to use this variable we call
> resolve_dynamic_type and pass in the address of the variable $0.
>
> When we resolve the DW_AT_data_location for the outer array type ($1) we
> use
> the address of the variable $0 as the value pushed when we execute
> DW_OP_push_object_address.
>
> Next we try to resolve the element type of the array.  This is the
> problem, an
> array has a single element type.  But if you look at the above then each
> 2nd
> rank array can have its own separate data location.  As we currently store
> the
> resolved data location on the type then we can only support a single data
> location for all elements.
>
> What currently happens with Tom's patch is that when resolving the element
> type
> we re-use the address of the variable $0 as the object address, each of
> the 2nd
> rank array types then points to the same area of memory, in our example
> above
> this would be the address 0x2000.
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[peter.mckinna at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #13 from peter mckinna <peter.mckinna at gmail dot com> ---
So that discussion of the data loc in only the outermost array
dimension prompted me to check if it would still work if I reverted the
fix and to my surprise it did.

So now maybe it's not a bug after all! I'm not sure.

It appears that if I have a DW_AT_data_location as an attribute of
any DW_TAG_array_type that is not the topmost array type then gdb will assert.

However, it's easy enough to not generate those data locations.

Is this just an example of the fuzziness of Dwarf?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

[andrew.burgess at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #14 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
Peter, I agree that it would be strange to split the data as I suggested, but I
didn't see any other reason why the compiler would be placing the
DW_AT_data_location on each dimension of the array type.

I don't think I agree with your diagnosis that we should just ignore the
DW_AT_data_location on more inner dimensions of the array - or rather I do
agree that in this case we should, but in general I still think my
interpretation is what the compiler is _actually_ describing, it's just not
what the compiler meant to describe.  Though I absolutely agree with you that
this case is ambiguous.  For a definitive answer I think we would need to
approach the DWARF committee for clarification, and hopefully get some
descriptive text added to the standard.

As for having multiple DW_TAG_subrange_types for a single DW_TAG_array_type,
then in the DWARF 5 spec at least you need to read section 5.5.  This
configuration is described here.  The parent array type can have a
DW_AT_ordering attribute which specifies if the bounds are ordered by row or
column, though most languages have a known default ordering.

Further there is an explicit example of this in appendix D.2.2.3.

The same (or very similar) information as can be found in section 5.5 also
appears as far back as the DWARF2 spec, so this isn't a recent change.

It appears from what you say that we only really need to track the
DW_AT_data_location on the outer most DW_TAG_array_type, I would be more
inclinded to handle this on the DWARF reader side, ideally wrapped in a
specific check for this particular compiler.

I do wonder though, given it sounds like this is an area of active development
on the compiler side, if the "easiest" (maybe just easiest for the GDB team!)
would be to change what DWARF is generated.  Given the links I've shared to the
DWARF above, I wonder if you might even want to consider going down the
multiple DW_TAG_subrange_type route?

-- 
You are receiving this mail because:
You are on the CC list for the bug.