suggestion: table visualizer

[gparmeggiani]

I think it would be useful to have a visualizer that displays generic data in a table. The idea would be that the table layout is specified in some sort of configuration format.

This could be used to add a simple "OS Awareness" support, where the table would fetch the list of tasks, their state, stack, context etc from a known location in memory.

Another use could be to have a table for each peripheral (when doing embedded debugging) and display the register values in the table.

What do you think?

[epasveer]

Hi,

Thanks for the interest in Seer.

Anything is possible, however, I'm not exactly clear what you're suggesting.

So far, the Array visualizer works with a "flat" chunk of memory. Are you suggesting to somehow "parse" that chunk of memory in some format that is definable by the user?

For example, currently you tell the visualizer what data type (float, int, double, short, ...) the memory is. It applies that type to the entire chunk of memory.

Are you saying a definable format can interpret the memory as a mixed set of data types? For example, 1 double, then 2 ints, then 4 floats, then 1 short, then repeat the sequence?

I might be missing your suggestion.

[epasveer]

Is there a current debugger out there that is doing what you suggest? I can look into that as an example.

[gparmeggiani]

Hi!

In my specific case, I'd like to have tables similar to the ones provided by this vscode plugin https://marketplace.visualstudio.com/items?itemName=mcu-debug.rtos-views

The info for populating the entries in the table would come from an array of structs. Each row is an item in the struct array. Each column is derived from the struct fields (not necessarily a 1-to-1 match). The user would specify how the data is derived. For example it could be interpreted as symbol address, or as a fixed-point value, or as a c enum item. a column can also be derived from 2 or more struct fields. I'm a bit thinking outloud here, but I think a generic approach would be to let the user provide to seer a path to an executable/script that takes the raw binary as input and provides a json(?) representation of the table row.

[epasveer]

So here's one of the views from that plugin.

So somewhere in the processes memory space, there is all this info?

[epasveer]

You mention tasks and threads. Is your application in Ada?

[gparmeggiani]

Exactly, the raw info to fill that table is in the process memory space.

Maybe, one approach would be to have a visualizer similar to the "struct visualizer" where it is possible to specify an address/symbol/etc and a user-provided script (e.g. in python). seergdb would invoke the script with the binary contents fetched from the process memory space. the script would reply with a format that seergdb understands and that it can use to render the table.

my application is in C. I mention tasks and threads because there is a RTOS (like FreeRTOS)

[epasveer]

Not many people know where this process info lives in memory. The linux kernel has a /proc/ tree where all this info can be retrieved. I suspect it's different in the embedded world.

I like the idea of a "call out" to do the work.

[epasveer]

Would this process memory space be one contiguous chunk of memory?

[gparmeggiani]

the "call out" makes it also more generic. It could be that the chunk of memory that gets converted into a table represents something else (not necessarily the OS scheduler state) that is specific to the application being debugged. Idk.. like I could imagine a game as the application being debugged. and somewhere in memory there's a list of players and their properties. These could be rendered in a table in seergdb.

it is a contiguous chunk of memory. I'd say if someone wants to visualize multiple chunks of memory, then multiple visualizer windows should be opened.

[epasveer]

Cool. I think I have a good grasp of your suggestion now. Let me give it some thought.

[gparmeggiani]

Worth taking into consideration that GDB already supports extensions and user defined commands. e.g. https://interrupt.memfault.com/blog/automate-debugging-with-gdb-python-api

So probably it could be that seergdb's view takes as input the gdb command to run. then the GDB user-defined command would return data in a seer-specific format that can be used to render the table.