[SRU] gdb 10.0 fails to examine any global variables in D programs
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:/
Related branches
- Matthias Klose (community): Approve
- Simon Chopin (community): Approve
-
Diff: 367 lines (+326/-0)5 files modifieddebian/changelog (+14/-0)
debian/patches/Make-sure-a-copy_insn_closure-is-available-when-we-h.patch (+103/-0)
debian/patches/Only-allow-closure-lookup-by-address-if-there-are-th.patch (+167/-0)
debian/patches/libiberty-auto-invoke-d-demangler.patch (+35/-0)
debian/patches/series (+7/-0)
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 |
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 |
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 |
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=727b7b1864973 c2645a554727afd 0eaf1303673a. I am unsure how demangle changes could affect the type resolution (maybe it's because GDB got confused about which entity to decode?)