Fix some plumbing and change the dwarf code to emit ref types.
text/plain
3252
Comments
Comment #0 by braddr — 2010-05-02T13:36:57Z
(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 by robert — 2010-05-02T13:44:31Z
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 by braddr — 2010-05-02T13:48:41Z
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 by robert — 2010-05-02T13:50:30Z
-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 by braddr — 2010-05-02T14:15:36Z
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 by robert — 2010-05-02T14:17:49Z
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 by bugzilla — 2010-05-02T16:14:03Z
I agree with Brad's comment 2.
Comment #7 by braddr — 2010-05-09T01:09:56Z
Created attachment 625
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 by braddr — 2010-05-09T04:29:06Z
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 by robert — 2010-05-09T07:29:05Z
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 by bugzilla — 2012-01-18T20:52:37Z
Can this be turned into a pull request?
Comment #11 by braddr — 2012-01-18T20:55:55Z
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 by leandro.lucarella — 2012-01-26T07:04:10Z
(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 by code — 2012-01-31T13:52:52Z
It's unrelated to pull 526 which fixed #4180.
Comment #14 by leandro.lucarella — 2012-02-01T02:22:04Z
(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 by braddr — 2012-02-01T21:03:43Z
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.
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 &
---