Created attachment 1704
Test case
From the prior conversation:
> Debugging issues:
> Stack allocated struct won't show values correctly (repro project attached)
> Supply metadata0.bin as commandline arg
> Place watch at lines 91 and 119, step and watch the values of `Frame f` and `Packet p` as they are populated with data
> Notice that those stack structs do not appear to be changing, and show rubbish values.
You can see the actual value in the hidden return value __HID1/__HID2
(you can see the symbol in the disassembly). dmd seems to ignore RVO
when emitting the debug info.
Comment #1 by r.sagitario — 2018-06-15T06:53:15Z
To be pedantic, this is an issue with dmd generated debug info. This is a simpler test case:
struct S
{
int a;
int b;
int c;
}
S foo()
{
S s = S(1, 2, 3);
s.a = 4; // break here, s shows junk, __HID1 has the expected values
return s;
}
void main()
{
S s = foo();
}
Here's the relevant snippet for x64 from the debug info as dumped by cvdump:
(00004C) S_GPROC32: [0000:00000000], Cb: 00000042, Type: 0x1006, rvo.foo
Parent: 00000000, End: 00000000, Next: 00000000
Debug start: 0000000E, Debug end: 0000003B
(00007B) S_REGREL32: rbp+00000010, Type: 0x1007, __HID1
(000090) S_ENDARG
(000094) S_REGREL32: rbp+FFFFFFE0, Type: 0x1004, s
(0000A4) S_END
Happens with OMF aswell, LDC doesn't generate any information for locals.
Comment #2 by turkeyman — 2018-06-18T04:13:42Z
Do you have any feel for the difficulty of this patch?
Is it just an if somewhere to detect if RVO and point the debuginfo at a different location?
It'd be really good to get a fix in 2.081 if possible, since the guys at work doing the evaluation all use symbolic debugging (in VisualD) very extensively, and they'll likely run into this within minutes of doing any real work. (I think one of them already has. He was complaining that it 'didn't work', but didn't elaborate how)
How motivated are they to pull bugfix patches like this in 2.081 after the beta has been cut? I didn't realise the next release was imminent..
> This is closed right?
IIRC fixes to stable no longer cause automatic closing. This is done when it is merged back to master to avoid spamming bugzilla with multiple messages.
I think the patch can still be improved, because the RVO variable is now magically converted to a pointer of a struct, but I have not been able to get RVO from C++ to see what happens there.
Comment #6 by turkeyman — 2018-06-21T18:25:05Z
> but I have not been able to
> get RVO from C++ to see what happens there.
I think if you build with C++14 (RVO guaranteed) and std::move the result to return value you should be able to force it.
Copy elision is all bundled up in move semantics.
Comment #7 by github-bugzilla — 2018-06-25T20:13:20Z