Created attachment 15447 [details] Minimal reproducible example (D source code) Hi there, I have discovered a D class type resolution regression since GDB 10 (it was working properly in GDB 9). Please find the reproducer in the file attached. You can compile the source code using either GDC or LDC2 (both can reproduce this issue): gdc -g -O0 t.d -o t To reproduce the bug, set the breakpoint to t.d:10 and examine the `i` global variable (using `p t.i`). GDB will then complain that "'t.i' has unknown type; cast it to its declared type." I found a workaround to this problem by using `p (uv*)_D1t1iCQf2uv`, but obviously, this is non-ideal: the developer may not know the mangled variable name easily. Since this looks like a regression, I did a simple `git bisect` that led me to this commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=727b7b1864973c2645a554727afd0eaf1303673a. I am unsure how demangle changes could affect the type resolution (maybe it's because GDB got confused about which entity to decode?)
Computing the "physname" decides that the symbol should be named: (top-gdb) p physname $37 = 0x2c70490 "_D1t1iCQf2uv" ... which is plainly wrong.
Ok, so while gdb's symbol reader is still really wrong here -- this physname stuff is pretty broken -- the root cause of this particular bug is also that libiberty does not auto-demangle D symbols. You can see this on the command line: prentzel. c++filt _D1t1iCQf2uv _D1t1iCQf2uv prentzel. c++filt -s dlang _D1t1iCQf2uv t.i To my eye this seems to be an oversight in cplus-dem.c, where the D code follows some earlier code; but perhaps the author didn't realize that the reason the Ada code does not check AUTO_DEMANGLING is that the Ada encoding isn't unambiguous in the way the D encoding is.
Testing a patch.
https://sourceware.org/pipermail/gdb-patches/2024-March/207686.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b1741ab0dafd899889faab6e862094a325a6b83c commit b1741ab0dafd899889faab6e862094a325a6b83c Author: Tom Tromey <tom@tromey.com> Date: Sat Mar 30 13:48:30 2024 -0600 libiberty: Invoke D demangler when --format=auto Investigating GDB PR d/31580 showed that the libiberty demangler doesn't automatically demangle D mangled names. However, I think it should -- like C++ and Rust (new-style), D mangled names are readily distinguished by the leading "_D", and so the likelihood of confusion is low. The other non-"auto" cases in this code are Ada (where the encoded form could more easily be confused by ordinary programs) and Java (which is long gone, but which also shared the C++ mangling and thus was just an output style preference). This patch also fixed another GDB bug, though of course that part won't apply to the GCC repository. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276 libiberty * cplus-dem.c (cplus_demangle): Try the D demangler with "auto" format. * testsuite/d-demangle-expected: Add --format=auto test.
Fixed.