Re: Remote query for structure layout

On 2021-04-02 6:05 p.m., David Blaikie wrote:
> One possibly "cheap" way would be for FreeRTOS to use the structure in
> C code to do the register stashing - rather than or in addition to/in
> some kind of hybrid manner along with the assembly. If that's not
> possible/would make the code harder to understand, then finding some
> other way to pin the data structure into the DWARF would be needed.
> 
> I'd be inclined to avoid adding a new attribute or other feature
> (though I wouldn't be entirely opposed to it - I can certainly think
> of other places where it may be useful to have a "whenever the
> compiler sees this type, ensure it makes it into the resulting DWARF
> no matter what" attribute) if reasonably possible - instead finding
> some lowest-common-denominator/highly reliable signal that compilers
> use to emit type information.
> 
> The simplest such signal is a global variable of the type (not a
> pointer to it, but of the type itself) - though probably has to be
> annotated in some way that ensures the compiler won't optimize the
> variable away even under LTO, etc. I'm not sure sure off-hand if I
> have a great way to do that portably (non-portably I guess there's
> various "exported" attributes that ensure the entity is visible even
> beyond the shared library/executable scope, and thus can't be
> optimized away - maybe such an attribute would be sufficiently
> portable for FreeRTOS's needs (ie: no less portable than the rest of
> the code already)).
> If such a variable would be problematic (taking up space in the image,
> etc) - maybe there's a way to ensure it through an extra nonce
> parameter (if it's C++ code, a parameter with a default argument - so
> the caller never has to think about it) to some core FreeRTOS function
> that won't be optimized away/removed as unused/etc. Again, has a
> runtime impact, though - maybe if it was zero-size (like a class
> template specialization with no members) & with the type as a template
> parameter /maybe/ that would suffice...
> 
> Happy to play around with mechanisms like that if it's of interest.

Ok, good to know that the intent is now clear.  I have no real opinion
on how this is achieved, since I am neither a FreeRTOS, OpenOCD or compiler
developer :).

Tim, Thomas: as for the GDB implementation part, feel free to send a
patch on gdb-patches, even if it's just a prototype.

Simon