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