[Bug d/31580] New: Regression in D class type resolution since GDB 10

[Bug d/31580] New: Regression in D class type resolution since GDB 10

[liushuyu011 at gmail dot com]

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

            Bug ID: 31580
           Summary: Regression in D class type resolution since GDB 10
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: d
          Assignee: unassigned at sourceware dot org
          Reporter: liushuyu011 at gmail dot com
  Target Milestone: ---

Created attachment 15447
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15447&action=edit
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?)

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |tromey at sourceware dot org
   Last reconfirmed|                            |2024-03-30

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Computing the "physname" decides that the symbol should be named:

(top-gdb) p physname
$37 = 0x2c70490 "_D1t1iCQf2uv"

... which is plainly wrong.

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
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.

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
Testing a patch.

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
https://sourceware.org/pipermail/gdb-patches/2024-March/207686.html

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
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.

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

[Bug d/31580] Regression in D class type resolution since GDB 10

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.1
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

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