[SRU] gdb 10.0 fails to examine any global variables in D programs

Bug #2059856 reported by Zixing Liu
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdb
Fix Released
Medium
gdb (Ubuntu)
Status tracked in Plucky
Jammy
Fix Committed
Undecided
Unassigned
Noble
Fix Released
Undecided
Unassigned
Oracular
Fix Released
Undecided
Unassigned
Plucky
Fix Released
Undecided
Unassigned

Bug Description

[Impact]

 * GDB 10.0 introduced a regression where it cannot inspect any global variables in any D programs compiled by any D compiler.
 * LDC2 and GDC upstream stated Focal does not have such a problem and stuck to this release for their test images.

[Test Plan]

Considering the following D program:

```
module t;

class uv {
    int i;
}

__gshared uv i;
int main() {
    i = new uv();
    return 0; // #break
}
```

If you build it using `gdc -g -O0 t.d -o t` or `ldc2 -o t.o t.d -g`, run the GDB using the following commands ...

```
b t.d:10
p t.i
```

... you will notice GDB will complain that "'t.i' has unknown type; cast it to its declared type."

[Where problems could occur]

  * The fix consists of a single line change to the demangler. The worst-case scenario would be breaking the demangling functionality of other programming languages. However, the newer D ABI uses a symbol mangling scheme that is very difficult to confuse with other programming languages.
  * Incorrect symbol de-mangling may also cause user confusion. However, the patch fixed a fundamental usability issue.

[Other Info]

  * Initial discussion in the LDC2 bug tracker: https://github.com/ldc-developers/ldc/issues/4389

Related branches

Revision history for this message
In , Zixing Liu (liushuyu-011) wrote :

Created attachment 15447
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?)

Revision history for this message
In , Tromey-b (tromey-b) wrote :

Computing the "physname" decides that the symbol should be named:

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

... which is plainly wrong.

Revision history for this message
In , Tromey-b (tromey-b) wrote :

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.

Revision history for this message
In , Tromey-b (tromey-b) wrote :

Testing a patch.

Revision history for this message
In , Tromey-b (tromey-b) wrote :
Changed in gdb (Ubuntu):
milestone: none → jammy-updates
summary: - gdb 12.1 fails to examine any global variables in D programs
+ gdb 10.0 fails to examine any global variables in D programs
Changed in gdb:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

The master branch has been updated by Tom Tromey <email address hidden>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b1741ab0dafd899889faab6e862094a325a6b83c

commit b1741ab0dafd899889faab6e862094a325a6b83c
Author: Tom Tromey <email address hidden>
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.

Revision history for this message
In , Tromey-b (tromey-b) wrote :

Fixed.

description: updated
description: updated
Changed in gdb:
status: Confirmed → Fix Released
summary: - gdb 10.0 fails to examine any global variables in D programs
+ [SRU] gdb 10.0 fails to examine any global variables in D programs
Vladimir Petko (vpa1977)
description: updated
Changed in gdb (Ubuntu Plucky):
status: New → Fix Released
Changed in gdb (Ubuntu Oracular):
status: New → Fix Released
Changed in gdb (Ubuntu Noble):
status: New → Fix Released
Changed in gdb (Ubuntu Jammy):
status: New → In Progress
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

Hello Zixing, or anyone else affected,

Accepted gdb into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1~22.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in gdb (Ubuntu Jammy):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-jammy
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (gdb/12.1-0ubuntu1~22.04.3)

All autopkgtests for the newly accepted gdb (12.1-0ubuntu1~22.04.3) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

linux-azure-6.5/6.5.0-1025.26~22.04.1 (arm64)
linux-gke/5.15.0-1071.77 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#gdb

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Zixing Liu (liushuyu-011) wrote :

Verification done using the method mentioned in the description

tags: added: verification-done verification-done-jammy
removed: verification-needed verification-needed-jammy
Revision history for this message
Chris Halse Rogers (raof) wrote :

Could you please confirm the version of the package that was tested? The output of `apt policy gdb` is good, but just the version tested is sufficient.

> If this package fixes the bug for you, please add a comment to this bug, **mentioning the version of the package you tested, what testing has been performed on the package** and change the tag from verification-needed-jammy to verification-done-jammy.

tags: added: verification-needed verification-needed-jammy
removed: verification-done verification-done-jammy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.