False assumption about GDB and memory reading when target is running?

[kyrreaa]

I keep reading that GDB does not allow for memory view (probing) while target is running, but coming from using Segger Studio, Code Wartrior, emBitz and other suites that all use GDB together with JLINK debuggers this appears strange to me. So I tested using VS Code and nRF53-DK that uses Segger JlinkGDBServerCL.exe as backend. This allows me to access the command interface via web as well as via VS Code. While target is running, a simple "mem32 0x2002411c,1" accesses one of my runtime variables, and indeed it is readable. At the same time I get messages that expression can not be evaluated in VS Code debug console.

Is this a big misconception? Is it in "the interface used" or in "the use of the interface"? It seems like a non-existent limitation to me.

[haneefdm]

It is true that many commands are disabled in GDB while the target is running. No gdb server I know of supports non-stop mode either. So, we are stuck.

But with (only) some gdb-servers (openocd, stlink, jlink), you can use a second instance of gdb connection and try to evaluate expressions, read memory, etc.

There is also another way which is to bypass gdb and talk directly to the gdb-server bit then you need special code for each server and replicate all the logic gdb has to figure out how to convert memory reads into datastructures. Note that mem32 is not a gdb command. It is a gdb-server/monitor command. RTOS view needs to talk to gdb to evaluate expressions and follow linked lists, etc. Memory reads are not sufficient without a TON of work.

But, using the Microsoft Debug Protocol, we can only talk to the first instance of gdb or whatever debugger is running. We can't talk to other things.

Another thing is that just to refresh the rtos-view once, it takes more than one second. Because everything is done via gdb. This is why commercial tools use FW instrumentation to notify change in state. This is done in lieu of polling and is far more accurate and much less bandwidth. But, it is intrusive. You could also use trace perhaps and this would require expensive probes which are all proprietary.

See also experimental https://github.com/Marus/cortex-debug/issues/810 which I also authored. We had to bend over backwards to get that working.

It seems like a non-existent limitation to me.

Perhaps, you can submit a PR? Very low priority for me.

[kyrreaa]

Thank you for the response. The reason for this is really being used to work in other IDE's with the exact same debugging tools and having this work flawlessly. When Nordic decided to change to VS Code our workflow fell apart. Debugging stepped 15 years back in time and features that were common no longer work, or apparently are not supported. Maybe Nordic could help with this and put more focus on it?

I will try raising a ticket with them about this. Non intrusive memory reads at high speed was not a problem before VS Code was forced on us. 2 Hz updates for 10+ variables worked fine and was very useful when tracking RTOS thread scheduling issues.

[haneefdm]

Doing ~10 scalar variables can be done at much higher rate than 2Hz. But to traverse the RTOS data structures requires lot more than 10 probes. I mean we are following pointers and linked lists in some cases.

Reading the stack is another very expensive operation.

Btw, why not continue to use Ozone? Even if it is just for debugging. Btw, what debugger does Nordic use in VSCode? They have their own, or they use cortex-debug?

In the end, we may have to enhance Microsoft's Debug Protocol and that is not that simple. I've done it. The reason you have disassembly, memory reads/views in VSCode is because of my proposals and it took a very long time to get the changes approved. But, they are very nice and at the same time very careful as it affects millions of users.

[kyrreaa]

The reason I posted here is because I thought they were using RTOS-Views since it came up in the interface after installing the Nordic extensions to VS Code. It may have been VS Code installing it based on it's own suggestions but I thought it was Nordic.

[haneefdm]

I have no idea what they are using...