[Bug debug/93988] invalid DWARF emitted for complex integer

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I wonder if there is (or should be) sth like DW_ATE_unsupported ... using
> DW_ATE_lo_user is indeed unfortunate but not wrong per-se.  Adding
> a DW_ATE_GNU_complex_int might be also possible (and support that from gdb).
> 
> So I'm not sure it's invalid DWARF.  It's just colliding vendor extensions
> (can gdb "switch" extensions if there are colliding ones?  does gdb
> autodetect
> vendors?)

Yeah, "invalid" was the wrong word to use.
More like, "undocumented gcc extension"; but one where the output
can't really be used.

Consider:

_Complex int x = 23i;
_Complex unsigned int y = 24i;

Here the base types can't readily be distinguished:

 <1><31>: Abbrev Number: 3 (DW_TAG_base_type)
    <32>   DW_AT_byte_size   : 8
    <33>   DW_AT_encoding    : 128      (HP_float80)
    <34>   DW_AT_name        : (indirect string, offset: 0x0): complex int
...
 <1><4c>: Abbrev Number: 3 (DW_TAG_base_type)
    <4d>   DW_AT_byte_size   : 8
    <4e>   DW_AT_encoding    : 128      (HP_float80)
    <4f>   DW_AT_name        : (indirect string, offset: 0x11): __unknown__


These have the same size and encoding, but in reality are different.

Also, I see the "__unknown__" there now -- better IMO to let gdb synthesize
a name instead.

To answer your questions, yes gdb can "vendor sniff" to see what extension to
use.
This isn't desirable but is done on occasion.

Right now gdb doesn't use any of the DW_ATE_HP_* extensions, so even that
wouldn't
need to be done.

However -- the code already needs to be changed, as shown above.  And if one is
doing
that, one might as well avoid a clash and document the extension anyhow.