Launchpad has imported 5 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=31580.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2024-03-30T00:23:30+00:00 Zixing Liu 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?)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856/comments/0

------------------------------------------------------------------------
On 2024-03-30T19:30:45+00:00 Tromey-b wrote:

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

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

... which is plainly wrong.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856/comments/1

------------------------------------------------------------------------
On 2024-03-30T19:36:27+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856/comments/2

------------------------------------------------------------------------
On 2024-03-30T19:49:00+00:00 Tromey-b wrote:

Testing a patch.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856/comments/3

------------------------------------------------------------------------
On 2024-03-30T20:10:51+00:00 Tromey-b wrote:

https://sourceware.org/pipermail/gdb-patches/2024-March/207686.html

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2059856/comments/4


** Changed in: gdb
       Status: Unknown => Confirmed

** Changed in: gdb
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/2059856

Title:
  gdb 10.0 fails to examine any global variables in D programs

Status in gdb:
  Confirmed
Status in gdb package in Ubuntu:
  New

Bug description:
  Summary:

   * 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.

  Reproduce steps:

  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."

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/2059856/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to