Visual D debugging messed up

[Rainer Schuetze]

On 12/06/2018 08:38, DigitalDesigns wrote:
> 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.

Sorry for the delay. I think it's more accurate and way easier to just 
make the compiler add the necessary debug information.

> 
> 
> --------------------------------
> 
> 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.

For most expressions, you can just select the expression and hover over 
it with the mouse: the tooltip will show the result (but doesn't work 
for string concatenations, for example).

> 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

C++ also shows the results of invoked functions, that would be nice to 
have. Not sure how it's done, though.

Last release allows executing functions without arguments in the watch 
window (mostly Win64 only due to ABI issues). Beware of side effects, 
the debugger doesn't know if the function is pure or not.