Re: arm-none-eabi, nested function trampolines and caching

[Ed Robbins <edd.robbins@googlemail.com>]

Hi David!

On Mon, 27 Nov 2023 at 17:23, David Brown <david.brown@hesbynett.no> wrote:
>
> On 27/11/2023 16:16, Ed Robbins via Gcc-help wrote:
> > Hello,
> > I am using gcc-arm-none-eabi with a cortex M7 device, with caches
> > (data/instruction) enabled. Nested function calls result in a usage fault
> > because there is no clear cache call for this platform.
> >
>
> I am not sure I understand you here.  Are you talking about trying to
> use gcc nested function extensions, implemented by trampolines (small
> function stubs on the stack)?  If so, then the simple answer is - don't
> do that.  It's a /really/ bad idea.  As far as I understand it, these
> are a left-over from the way nested functions were originally
> implemented in other gcc languages (Pascal, Ada, Modula-2), which now
> handle things differently and far more efficiently.  Trampolines were a
> convenient way to implement nested functions some 30 years ago, before
> caches were the norm, before anyone thought about security, before
> processors had prefetching, and before people realised what an
> appallingly bad idea self-modifying code is.
>
> If you want to use nested functions, use a language that supports nested
> functions, such as Ada, or use C++ with lambdas (which are a bit like
> nested functions only much better).

I am aware of the alternative languages and the implementation
limitations, but I didn't ask if it is a good idea or not!

>
> > Is there a way to provide the required functions without rebuilding gcc? I
> > have been looking at the source and, as far as I can tell, there is not.
>
> I can think of at least four ways :
>
> 1. The SDK for your microcontroller, provided by the manufacturer, will
> have headers with cache clear functions.
>
> 2. The ARM CMSIS headers - also available from your manufacturer - has
> intrinsic functions, including cache clear functions.
>
> 3. gcc has a generic "__buitin__clear_cache" function :
> <https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005f_005f_005fclear_005fcache>
>
> 4. gcc supports the "ARM C Language Extensions", which include cache
> control intrinsics:
>
> <https://gcc.gnu.org/onlinedocs/gcc/ARM-C-Language-Extensions-_0028ACLE_0029.html>
> <https://developer.arm.com/documentation/ihi0053/latest/>
>

I'm aware of how to perform a cache invalidate/clean, but that isn't
the question.

>
> >
> > But there also doesn't look to be a clean way to implement this: It appears
> > that this is done on an operating system basis, and when running bare metal
> > it is not clear where the code would live.
>
> There is no "clean" way to handle the appropriate cache invalidation,
> because there is no clean way to get the addresses you need for
> invalidating the instruction cache.

Yes, there is, and that is what my question is about. The gcc
documentation on trampolines [1] details this to some extent. It says that
the target should define CLEAR_INSN_CACHE(beg, end) and it will be
called with the correct addresses when the trampoline is initialised.
Looking at the gcc source, arm.cc calls
maybe_emit_call_builtin___clear_cache with the correct addresses when
it initialises the trampoline, and
maybe_emit_call_builtin___clear_cache calls __clear_cache if
CLEAR_INSN_CACHE is defined. The question is about where to place this
clear cache definition for a "none" target.

(Cleanly invalidating the
> instruction cache for other purposes, such as during firmware upgrades,
> is no problem.)

Yes, we do this already during firmware upgrades.

Best regards,
Ed

[1]  https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html