Variables window <unknown>

[microwavesafe]

I am having a problem with the Variables window. Seemingly randomly the local variables will all be set to \<unknown> on a break point. I have checked and the call stack looks OK and you can also look at the variables by setting a watch.

Once this has happened the local variables will not be shown again until I disconnect the debugger and reprogram / reconnect the target.

I am using version 0.3.7-pre2 of the extension and version 1.45.1 VSCode. I've attached the debug log output, hopefully it will help.

variable_unknown_log.txt

[haneefdm]

All out of ideas. What if the breakpoint is slightly before or after?

I have a hack in mind but have to sleep on it.

[AndrewCapon]

It doesn't seem to make any difference where the breakpoint is as far as I can see.

I have some more info though.

If I run the debugger and don't break at all. Then do a restart/build and add a breakpoint then the variable window is working.

So this problem only occurs if a breakpoint has been hit previously to the restart.

[AndrewCapon]

And some more info:

If I run the debugger and pause, Then do a restart/build and add a breakpoint then the variable window is working.

If I have hit a breakpoint, then continue, then do a restart/build it is broken.

So it seems to be breakpoint related

[haneefdm]

Having gotten some sleep, I am getting a better picture. Back to the first trace

29-interpreter-exec console "load"
-> ~"`/Volumes/Crucial X8 2TB/Development/daisy/SimpleFMSynth/build/SimpleFMSynth.elf' has changed; re-reading symbols.\n"
`/Volumes/Crucial X8 2TB/Development/daisy/SimpleFMSynth/build/SimpleFMSynth.elf' has changed; re-reading symbols.

First of all, this will NOT work in Cortex-Debug and can cause silent failures. If the executable changes, we don't re-read the symbols and re-create all the globals/statics. Chances are they are still the same but not guarnteed. GDB has re-read the symbols and our world view vs GDB can now be different.

When gdb reloads the symbols, we have no idea what it did with all the temporary gdb-variables we created. Sems like they are still there but may not be reliable. Use at your own risk.

This does not explain why it works after the first breakpoint but results cannot be trusted.

Bottom line, we do not expect your executable to have changed once the session starts. If we did, our Restart handling would have been different -- as in you would not have to add a "load" command yourself.

I know MS has changed the definition of a 'Restart' a couple of times and they didn't used to trigger a re-build on a 'Restart'. Now they do. They went back and forth on this. This is why we introduced the 'Reset' button and most people like this button more as we know exactly what it does and does not rely on MS changing their policy. As it stands, it is much cleaner to stop the session and start over. There are many things that are done at startup that aren't done on a Restart.

Btw, with openocd, you can use it to load a new image instead of using gdb. To do this, you need to convert your elf file to a hex file and use the command

    "monitor program {/Volumes/Crucial X8 2TB/Development/daisy/SimpleFMSynth/build/SimpleFMSynth.hex}"

I don't recommend the above because if you rebuild. That reminds me. If you use and RTOS OpenOCD/JLink/etc will only detect an RTOS at the start. Never again. Another reason why Restart is bad.

I would like to close this issue and start new ones if needed. We kinda hijacked this issue which at this point is unrelated.

[AndrewCapon]

Ah Ok, I get it.

I have already got into the habit of stopping and starting again.

[AndrewCapon]

Thanks for all the help as well, very good of you.