add lexical scope to local symbols in codeview debug info
text/plain
23321
Comments
Comment #0 by r.sagitario — 2009-12-29T02:47:59Z
Consider
import std.stdio;
void main()
{
for(int i = 0; i < 10; i++)
writefln("1 - %d", i);
for(int i = 0; i < 10; i++)
writefln("2 - %d", i);
}
This declares two different variables "i", but the debugger only shows the value of the first variable, even while stepping through the second loop. (The list of local variables does show two variables "i".)
This is caused by DMD not emitting any life time info of local variables.
Comment #1 by r.sagitario — 2009-12-29T02:57:56Z
Created attachment 536
add lexical scope to local symbols in codeview debug info
The patch consists of two parts:
1. modify the parser to remember the end of scope statements.
2. transfer the life-time info to the debug info.
The latter is straight forward, but the second part is a bit complicated.
As scoping information is lost in the code generation, only the line of declaration and the end of the enclosing scope is remembered by the symbol. The life-time of the variable in terms of code byte offset and length is then reconstructed from the line number info. This is only implemented for CodeView information, as I don't know anything about the other formats.
Another complication: optlink removes the corresponding debug entries, so I had to use pseudo-symbols to get this info to cv2pdb and convert them back there.
This might confuse other tools, so maybe this feature should be enabled by some command line switch only.
Comment #2 by bugzilla — 2012-01-18T20:55:44Z
Want to do a pull request for this?
Comment #3 by r.sagitario — 2012-01-19T13:42:22Z
I'd like to if there is a chance to avoid the ugly workaround regarding optlink: Will it be a large issue to add support for S_BLOCK32/S_END debug entries to optlink?
Comment #4 by bugzilla — 2012-01-19T17:56:43Z
That would be a great deal of work, mainly because the optlink codeview code is a giant inscrutable mess.
Comment #5 by r.sagitario — 2012-01-20T00:31:22Z
So you are fine with the workaround to emit symbols to be translated back to the block statements? This will create strange symbols "@sblk" and "@send" if you happen to work with the debug info without using cv2pdb.
Comment #6 by bugzilla — 2012-01-20T00:34:34Z
No, I'm not really fine with that. I didn't realize that would happen.
Comment #7 by r.sagitario — 2012-01-21T13:49:51Z
So I guess we are kind of stuck. Is it really much worse than all the temporaries generated as local variables by dmd?
Do you see another possibility to pass variable life time information to the debugger?
Comment #8 by bugzilla — 2012-01-21T13:56:03Z
Maybe we should defer this then until the linker can be improved.
Comment #9 by ehysta — 2013-11-18T00:25:05Z
*** Issue 11516 has been marked as a duplicate of this issue. ***
Comment #10 by dlang-bugzilla — 2013-11-20T19:45:00Z
I think that it's unlikely that the linker will be considerably improved at this point.
Barring merging cv2pdb into DMD, would it make sense to add a -gp switch, which would cause DMD to emit debug information with cv2pdb extensions?
Comment #11 by r.sagitario — 2013-11-23T02:58:26Z
(In reply to comment #10)
> I think that it's unlikely that the linker will be considerably improved at
> this point.
>
> Barring merging cv2pdb into DMD, would it make sense to add a -gp switch, which
> would cause DMD to emit debug information with cv2pdb extensions?
I just noticed that optlink has support for S_BLOCK32/S_END, it might just be broken. I'll have a closer look...