Visual D debugging messed up
DigitalDesigns
DigitalDesigns at gmail.com
Tue Jun 12 06:38:43 UTC 2018
On Monday, 11 June 2018 at 17:50:42 UTC, Rainer Schuetze wrote:
>
>
> On 11/06/2018 09:04, DigitalDesigns wrote:
>> On Sunday, 3 June 2018 at 07:03:08 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 03/06/2018 03:14, DigitalDesigns wrote:
>>>> I'd like to make a similar request if you don't mind:
>>>>
>>>> When using nested functions, only the types local to the
>>>> function are shown in the locals. It would be nice if higher
>>>> up variables would be shown. There is a this pointer but the
>>>> value is invalid.
>>>>
>>>> void foo(int x)
>>>> {
>>>> int y;
>>>> void bar(int z)
>>>> {
>>>> int c;
>>>> }
>>>> }
>>>>
>>>> When debugging bar all I see is c and z but not x and y.
>>>> This would work for all nested functions which are functions
>>>> that have a "this pointer". foo itself might be nested.
>>>>
>>>
>>> Unfortunately, no debug information is emitted by dmd for the
>>> function closure. LDC works better in that regard.
>>
>> Could a stack trace not work? It might require some slueth
>> work but if one can determine that the function was nested
>> then one knows the the caller was the parent function... then
>> backtrack and get the locals of that function. Would be tricky
>> to be able to do it precisely.
>
> Looking at the stack might work in some cases, but the closure
> can be allocated on the heap, too. dmd should just emit that
> information as LDC and GDC do.
Well, for locally called nested functions it should work. The
callee is the parent function. I can only see a problem when the
nested function is passed around and called somewhere else. If
there were a way to tell for sure which case one was in, then it
would work.
Maybe a better way is to show special "super" variable which
holds the closure of the caller.
The idea is this: For any function call, capture the "closure" of
the current scope(you have this because all the locals and auto
are shown from this scope right before the call). Now, once
inside the call this "super" just shows the history of the
caller's closure.
Basically what happens now is when a function is about to be
called, the current state is shown. When the function is called,
the current state is shown for the called function but the
previous one is completely lost.
Simply "remember" the previous state and show it in a special
variable so one can access the data.
See, the problem with the following code is:
auto foo(int i)
{
auto bar() { return i + 4; }
return bar + 5;
}
Putting a BP on the first return statement hides i! There is no
way to evaluate what i is without creating a temporary local,
which is a pain just to see i.
Instead, the compiler, before it called bar, simply keeps track
of the data(it has the addresses, names, types, etc) and show it
somewhere in the debug window(I'd suggest an expandable variable
like __super__).
It would then be easy to make it recursive so that __super__
contains __super__, the function that called the function that
called the current function.
This is sort of like a stack trace and might be easy to implement
since it is just tracking data that it already has. The problem
is the stack doesn't always show the logical nesting. Not sure if
visual D can figure it out (determine if a function is about to
be called/entered to get information).
In fact, a stack trace sorta already does this as one can go back
in time and look at variables. So, maybe just showing the
previous function info would be the best way.
--------------------------------
Not sure if visual D can do this but sometimes when I do
computations on a function call: foo(i + x, "43"~tmp); I have to
create a temp variable so I can see the result. This is time
consuming.
It would be cool if visual D showed the results of either the
current function call(the parent, which means I just have to step
in the line) or the function call at the current line.
could have, in the autos, something like
arg1 = 5
arg2 = 43df34saa
Thanks, just suggestions of course. Getting the interfaces to
show information was a tremendous help!
More information about the Digitalmars-d-ide
mailing list