[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988 Andrew Pinski changed: What|Removed |Added Keywords||wrong-debug --- Comment #5 from Andrew Pinski --- http://gcc.gnu.org/ml/gcc/2001-11/msg00790.html
[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
--- Comment #4 from Tom de Vries ---
(In reply to Tom Tromey from comment #2)
> Also, I see the "__unknown__" there now -- better IMO to let gdb synthesize
> a name instead.
Attempt to synthesize the name in gcc:
...
commit d2b7f315ad976ff18c71eef88098dbf5ab5e6544
Author: Tom de Vries
Date: Wed May 29 09:42:55 2024 +0200
[debug] Emit name attribute for complex long and complex long long
As noted in PR debug/93988, the types "complex long" and "complex long
long"
have a name attribute with value "__unknown__".
Fix this by using "complex long" and "complex long long" instead.
Tested on x86_64.
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 4e93262f75a..8ec3856873e 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -14076,6 +14076,19 @@ modified_type_die (tree type, int cv_quals, bool
reverse,
TYPE_PRECISION (type));
add_name_attribute (mod_type_die, name_buf);
}
+ else if (TREE_CODE (type) == COMPLEX_TYPE
+ && TYPE_NAME (TREE_TYPE (type)) != NULL_TREE)
+ {
+ const char complex_prefix[] = "complex ";
+ const char *part_name
+ = IDENTIFIER_POINTER (TYPE_IDENTIFIER (TREE_TYPE (type)));
+ size_t sizeof_name_buf
+ = sizeof (complex_prefix) + strlen (part_name);
+ char *name_buf = XNEWVEC (char, sizeof_name_buf);
+ snprintf (name_buf, sizeof_name_buf, "%s%s", complex_prefix,
part_name);
+ add_name_attribute (mod_type_die, name_buf);
+ XDELETEVEC (name_buf);
+ }
else
{
/* This probably indicates a bug. */
...
[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #3 from Tom de Vries ---
Using this:
...
commit cccb4b98b86e50d087ea9ec8eea95d2149eaa393
Author: Tom de Vries
Date: Wed May 29 08:43:34 2024 +0200
[debug] Fix dwarf for complex int type
The proposal https://dwarfstd.org/issues/210218.2.html was accepted into
dwarf v6,
and introduces 4 new base type encodings:
- DW_ATE_complex_signed
- DW_ATE_imaginary_signed
- DW_ATE_complex_unsigned
- DW_ATE_imaginary_unsigned
Add these, and use DW_ATE_complex_signed/DW_ATE_complex_unsigned to emit
debug
info for complex int.
PR debug/93988
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5b064ffd78a..4e93262f75a 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13331,6 +13331,15 @@ base_type_die (tree type, bool reverse)
case COMPLEX_TYPE:
if (SCALAR_FLOAT_TYPE_P (TREE_TYPE (type)))
encoding = DW_ATE_complex_float;
+ else if (INTEGRAL_TYPE_P (TREE_TYPE (type)))
+ {
+ if (!(dwarf_version >= 6 || !dwarf_strict))
+ encoding = DW_ATE_lo_user;
+ else if (TYPE_UNSIGNED (TREE_TYPE (type)))
+ encoding = DW_ATE_complex_unsigned;
+ else
+ encoding = DW_ATE_complex_signed;
+ }
else
encoding = DW_ATE_lo_user;
break;
diff --git a/include/dwarf2.def b/include/dwarf2.def
index 66c7fa1220f..7ed43e5cb3c 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -728,6 +728,11 @@ DW_ATE (DW_ATE_UTF, 0x10)
/* DWARF 5. */
DW_ATE (DW_ATE_UCS, 0x11)
DW_ATE (DW_ATE_ASCII, 0x12)
+/* DWARF 6. */
+DW_ATE (DW_ATE_complex_signed, 0x13)
+DW_ATE (DW_ATE_imaginary_signed, 0x14)
+DW_ATE (DW_ATE_complex_unsigned, 0x15)
+DW_ATE (DW_ATE_imaginary_unsigned, 0x16)
DW_ATE_DUP (DW_ATE_lo_user, 0x80)
DW_ATE_DUP (DW_ATE_hi_user, 0xff)
...
we get:
...
<1><39>: Abbrev Number: 4 (DW_TAG_base_type)
<3a> DW_AT_byte_size : 8
<3b> DW_AT_encoding: 19 (unknown type)
<40> DW_AT_name: complex int
...
[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988 --- Comment #2 from Tom Tromey --- (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.
[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-02 Version|unknown |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- 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?) The other DW_ATE_lo_user uses are to _avoid_ invalid dwarf. Using DW_ATE_hi_user might be less prone to colliding with other vendor extensions tho.
