Re: Remote query for structure layout

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-03-30 6:44 p.m., David Blaikie wrote:
> If it's "just" some user-code, is there a variable of the desired type being declared around the function call? 

AFAIK, this type wouldn't be used by the FreeRTOS code at all, so no.
Again, here's my understanding, hopefully it's close enough to the
reality.

When a trap occurs, FreeRTOS saves the current task's register values on
the task's stack, using some arch-specific assembly code.  For example,
for RISC-V:

    https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/534eba66ce4a5bda45d5edeeb81ac5a3cf6d0df8/portable/GCC/RISC-V/portASM.S#L121

The way these registers are pushed is an implementation detail of
FreeRTOS.  And we can imagine that it can vary depending on the
compile-time FreeRTOS configuration, which OpenOCD doesn't know about.

To get register values of scheduled out tasks, OpenOCD needs to
interpret these register values from the tasks' stacks.

So Tim's suggestion is: have FreeRTOS declare a structure that has the
exact layout as the saved registers on the stack:

struct freertos_saved_regs {
  int x1;
  int x5;
  int x6;
  ...
};

Consumers could read that structure's layout from the DWARF info, and
read the register values based on that.  That would be a lot more robust
than hard-coding in the consumers how FreeRTOS stores things.

However, since that struct would never actually be used by FreeRTOS'
code, the compiler won't emit it.  Hence the need to find a way to force
the compiler to include it in the DWARF.

Does that clarify the situation?

Simon