D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 4149 - refs displayed as pointers in gdb
Summary: refs displayed as pointers in gdb
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: Martin Nowak
URL:
Keywords: DebugInfo, pull
Depends on:
Blocks: 4044
  Show dependency treegraph
 
Reported: 2010-05-02 13:36 UTC by Brad Roberts
Modified: 2015-06-17 21:02 UTC (History)
6 users (show)

See Also:


Attachments
Fix some plumbing and change the dwarf code to emit ref types. (3.18 KB, patch)
2010-05-09 01:09 UTC, Brad Roberts
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Brad Roberts 2010-05-02 13:36:57 UTC
(gdb) list inline.d:1
1  module test.d;
2
3  void foo(ref int x)
4  {
5      ++x;
6  }
7
8  void bar()
9  {
10     int x = 0;
11
12     foo(x);
13 }
14
15 void main()
16 {
17     bar();
18 }

(gdb) break 5
Breakpoint 1 at 0x804910d: file inline.d, line 5.
(gdb) run
Breakpoint 1, test.d.foo (x=0xbffff62c) at inline.d:5
5      ++x;
(gdb) print x
$1 = (int *) 0xbffff62c

Assuming I'm understanding the dwarf records correctly, foo's argument:
 <2><a2>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <a3>   DW_AT_name        : x
    <a5>   DW_AT_type        : <0x69>
    <a9>   DW_AT_location    : 2 byte block: 91 7c    (DW_OP_fbreg: -4)

And type 0x69:
 <1><69>: Abbrev Number: 4 (DW_TAG_pointer_type)
    <6a>   DW_AT_byte_size   : 4
    <6b>   DW_AT_type        : <0x62>


Dwarf formally supports a reference type according to the spec.
Comment 1 Robert Clipsham 2010-05-02 13:44:31 UTC
This is done because C does not have reference types, and no debugger currently supports the debug output produced by dmd when using -g. When using -g dmd should, as you say, use the DWARF reference type, which it does not currently do. When using -gc, it should be a pointer as it is now. I'll try and put a patch together later today. As a side note, classes should be reference types too, rather than acting as pointers as they do currently.
Comment 2 Brad Roberts 2010-05-02 13:48:41 UTC
Depends on if gc implies c, c++, or 'as much as is supported in the built-in debug format without extension'. 

I'd argue for the last definition.  Given that dwarf supports it without extension, I'd argue that it should use it.  I'd argue that -g should be built-in + d extensions.
Comment 3 Robert Clipsham 2010-05-02 13:50:30 UTC
-gc means act as C. I think I'm going to talk to Walter about this actually, as the debugging situation for D could be far better.
Comment 4 Brad Roberts 2010-05-02 14:15:36 UTC
I've been looking at how to patch up that part of the code, and it looks like the ref-ness has been lost at this layer:

(gdb) print *t
$2 = {id = 4660, Tty = 29, Tflags = 0, Tmangle = 7 '\a', Tcount = 1, Tnext = 0x81ffd20, {Tdim = 0, Tel = 0x0, Tparamtypes = 0x0, Ttag = 0x0, Tident = 0x0, Tkey = 0x0}, Texcspec = 0x0}
(gdb) print t->Tnext
$3 = (TYPE *) 0x81ffd20
(gdb) print t->Tnext[0]
$4 = {id = 4660, Tty = 10, Tflags = 0, Tmangle = 0 '\000', Tcount = 3, Tnext = 0x0, {Tdim = 0, Tel = 0x0, Tparamtypes = 0x0, Ttag = 0x0, Tident = 0x0, Tkey = 0x0}, Texcspec = 0x0}

Tty 29 == 0x1d == TYnptr

If it was still a TYnref, it'd be easy.
Comment 5 Robert Clipsham 2010-05-02 14:17:49 UTC
It is easy, I wrote the patch that adds support for ref types to the debug info ;) The refness isn't lost, it just uses the same case statement, and thus gets replaced. I'm about to write a patch for it now :)
Comment 6 Walter Bright 2010-05-02 16:14:03 UTC
I agree with Brad's comment 2.
Comment 7 Brad Roberts 2010-05-09 01:09:56 UTC
Created attachment 625 [details]
Fix some plumbing and change the dwarf code to emit ref types.

The ref'ness was lost before it got into the dwarf stage, but also easy to fix, assuming that Walter is right about the backend being ready to handle TYref's now.

I've attached the diff I've whipped up.  It does work to emit the right debug info, but I haven't tested it on much more than the simplest code (specifically, the code at the top of this bug report).

A snippit from a gdb session:

Breakpoint 1, test.foo (x=@0xbffff62c) at inline.d:5
5      ++x;
(gdb) print x
$1 = (int &) @0xbffff62c: 0
(gdb) next
0x08049112 in test.foo (x=@0xbffff62c)
(gdb) print x
$2 = (int &) @0xbffff62c: 1

So, gdb is using C++ style demangling, but that can be addressed by someone working on gdb.
Comment 8 Brad Roberts 2010-05-09 04:29:06 UTC
Looks like one more minor change is needed to build phobos with these changes:

backed/cgcod.c:
@@ -1508,6 +1508,7 @@ regm_t regmask(tym_t tym, tym_t tyf)
         case TYnptr:
         case TYsptr:
         case TYcptr:
+        case TYref:
             return mAX;
         case TYfloat:
         case TYifloat:
Comment 9 Robert Clipsham 2010-05-09 07:29:05 UTC
If this patch is accepted, we should probably change the DW_AT_language to be C++ instead of C with -gc, and update the help message to say so.
Comment 10 Walter Bright 2012-01-18 20:52:37 UTC
Can this be turned into a pull request?
Comment 11 Brad Roberts 2012-01-18 20:55:55 UTC
Last time I played with this diff on current code, it caused failures.  I haven't looked at in any detail in ages and I'm fairly sure it's rather incomplete now that I know more about the backend.

The bug is still real though.
Comment 12 Leandro Lucarella 2012-01-26 07:04:10 UTC
(In reply to comment #6)
> I agree with Brad's comment 2.

What's the relation between this and pull request 526[1] (commit e81dbc2 in dmd-1.x) that has been merged recently. At least according to the pull request, the improved usage of DWARF is only activated when -g is specified. Should that be changed for -gc? What about bug 3389? I think Robert's suggestion about having a -gd for D extensions and -g for standard debugging stuff would be better.

Right now the situation with -g/-gc is far from ideal.

[1] https://github.com/D-Programming-Language/dmd/pull/526
Comment 13 Martin Nowak 2012-01-31 13:52:52 UTC
It's unrelated to pull 526 which fixed #4180.
Comment 14 Leandro Lucarella 2012-02-01 02:22:04 UTC
(In reply to comment #13)
> It's unrelated to pull 526 which fixed #4180.

I'm talking about the comment 2 by Brad:

> Depends on if gc implies c, c++, or 'as much as is supported in the built-in
> debug format without extension'. 
> 
> I'd argue for the last definition.  Given that dwarf supports it without
> extension, I'd argue that it should use it.  I'd argue that -g should be
> built-in + d extensions.

Walter expressed he agree with this comment in comment 3.

AFAIK this pull request works for -g instead of -gc, even when it uses standard DWARF features, which goes against that comment.

In the bug 3389 that you just closed, Robert Clipsham makes what for me is a good point:

> -g not working is how it's meant to be, at least until gdb adds support for the
> D extensions to DWARF. I've hopefully fixed the remaining bugs with -gc (on
> linux at least). My solution to this would be to add in a -gd, and make -g an
> alias to -gc until better support for debug info is added to debuggers. This
> way users get working debug output with -g, and don't blame it on a buggy dmd
> :)

At least this will be more familiar with people used to GCC command line arguments (which is probably 100% of the *nix world), where -g is the default for debug and you have, for example -ggdb for GDB extensions.

AFAIK there is no clear direction about this. But maybe is a topic for another bug report, I think I'll reopen bug 3389 because the root issue in that bug is what's being discussed here.
Comment 15 Brad Roberts 2012-02-01 21:03:43 UTC
Please stop cluttering this bug report with discussion about the meaning of -g, that's a solved problem.  This report is about preserving 'ref'ness through the backend and dwarf debug data.
Comment 16 Martin Nowak 2012-02-02 15:44:42 UTC
https://github.com/D-Programming-Language/dmd/pull/687

Based on patch but had to add another change to e2ir.c.
Comment 17 Iain Buclaw 2014-02-14 02:22:13 UTC
Confirmed on Linux, changing platform from 'Other', 'Windows' to 'All', 'All'

---
void foo(ref int a)
{
  a = 42;
}

void main()
{
  int i;
  foo(i);
  assert(i == 42);
}
---

(gdb) break test.foo(ref int) 
Breakpoint 2 at 0x41705c: file test.d, line 3.
(gdb) continue
Continuing.

Breakpoint 2, test.foo(ref int) (a=0x7fffffffde68) at test.d:3
(gdb) ptype a
type = int *

---

Also, cannot reproduce on GDC, so this is DMD-specific.

(gdb) break test.foo(ref int) 
Breakpoint 2 at 0x402c0f: file test.d, line 3.
(gdb) continue
Continuing.

Breakpoint 2, test.foo(ref int) (a=@0x7fffffffdf4c: 0) at test.d:3
(gdb) ptype a
type = int &

---
Comment 19 github-bugzilla 2015-03-21 09:47:32 UTC
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f54855a15150a3f515813051bd283ac5fcfb04cc
fix Issue 4149 - refs displayed as pointers in gdb

- use TYnref for reference variables
- emit dwarf debug info for references
- handle TY*ref in backend
- add TYFLref to tyscalar

https://github.com/D-Programming-Language/dmd/commit/ed67724292dd1e60ff75b2d2392782908df92b1f
Merge pull request #4495 from MartinNowak/fix4149

fix Issue 4149 - refs displayed as pointers in gdb
Comment 20 github-bugzilla 2015-03-28 01:23:07 UTC
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/2f4715db31e59f9514f14b704e6b3bee706a7900
test for Issue 4149 - refs displayed as pointers in gdb

https://github.com/D-Programming-Language/dmd/commit/f562afe18d20c6f8ecc838e450b7bb439a878c11
Merge pull request #4523 from MartinNowak/test4149

test for Issue 4149 - refs displayed as pointers in gdb