To what extent does this extension rely on plugins for the JLink GDB server? about cortex-debug HOT 4 CLOSED

You may be mistaken. Neither rtos-view nor cortex-debug uses the JLink plugin and not sure if there is such a thing. I wrote both. They complement each other rather than overlap.

You should read the architecture of our debugger (applies to most gdb based debuggers)
https://github.com/Marus/cortex-debug/wiki/Cortex-Debug-Under-the-hood

You may be confusing a gdb-server with a plugin. Bottom line is

• cortex-debug works with many gdb-servers, JLink included. But it doesn't really talk to any gdb-server for debugging. Instead, it talks to gdb.
• rtos-view doesn't even talk to gdb. It instead uses the debugger protocol. Both cortex-debug and rtos-views use this protocol. cortex-debug is more of a provider and rtos-view (and memory/peripheral views) is a consumer. This way, rtos-view can be debugger-independent and it does work with many debuggers.

You are also confusing the task view from VSCode (data provided by cortex-debug) with what this extension does. Again the protocol I mentioned is used and VSCode is the consumer. This extension shows you what task view does not show and cannot show. rtos-view can show task info even when the gdb-server is running in bare metal mode (ie, with no task/rtos support). We also don't want to duplicate what VSCode already does.

All the source code is public (there is not much) and you should study it. Also read the documents, specifications, open/closed issues.

Furthermore rtos-view plugin does its job better since it asks GDB client which have full knowledge how task control block structure looks like and user dont need to operate on raw memory offsets

Ummmm. No. GDB does not know anything about any RTOS or what a TCB is. gdb-servers and rtos-view do know about TCBs. GDB simply provides a service that can help with converting a symbol name to an address or value just like for any other C/C++/Rust/etc. language. GDB has an abstract construct for threads and gdb-servers use that concept to present/convert/emulate RTOS Tasks into gdb's idea of a thread. Some might argue RTOS tasks are similar to OS processes but I disagree. Very large topic.

Instead of looking at this specifically about your RTOS and your toolchain, you should try to research first the general concepts.

from cortex-debug.

In order to use JLink probes and see custom RTOS tasks in call stack view (screenshot below) there is a need to develop a JLink GDB server plugin [3], there is no need to develop this custom RTOS support in cortex-debug and rtos-view plugins.

Each RTOS in JLink requires a couple of hundred lines of C code to create support for it. They provide a free SDK upon request. You probably never asked them. As you saw, this is the most important document

https://www.segger.com/products/debug-probes/j-link/tools/j-link-gdb-server/thread-aware-debugging/

I think the SDK provides examples.

You will not worry about how gdb and JLink communicate or with gdb thread MI commands. GDB and JLInk use another protocol (serial protocol) to talk to each other and it looks nothing like MI. Also, gdb will never interact with your JLink RTOS plugin.

Btw, the same is true with any gdb-server (openocd, etc.) but the exact mechanism and language used may be different.

Thank you for this short introduction, sorry I too often skip research before creating code

That makes you dangerous 😄

Hope you now understand why rtos-view does not duplicate work done by all the other tools. It helps debug/monitor the kernel data structures, task states, stack usage, and may even display tasks not shown by gdb-servers.

from cortex-debug.

Thank you for this short introduction, sorry I too often skip research before creating code

I will try to answer my original questions, please review my answer if I am correct.

I was wrong to think that the cortex-debug plugin is responsible for thread aware debugging, whereas the core responsibility in understanding RTOS data structures lies within the GDB client and server. GDB support many thread related facilities [1], I can see how it works by watching the GDB/MI communication log, there is a bunch of GDB/MI commands to gather threads info [2]

In order to use JLink probes and see custom RTOS tasks in call stack view (screenshot below) there is a need to develop a JLink GDB server plugin [3], there is no need to develop this custom RTOS support in cortex-debug and rtos-view plugins.

The feature that interests me the most: tasks in call stack view

[1] https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_24.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI-Thread-Commands.html
[3] https://www.segger.com/products/debug-probes/j-link/tools/j-link-gdb-server/thread-aware-debugging/

from cortex-debug.

Plugin SDK is now free to download, you just need to register on JLink website. Running new plugin is pretty easy, there is a support for printing debug info in JLink GDB Server logs, so its easy to start working.

from cortex-debug.