On Tue, 28 Nov 2023 at 07:21, Matthias Pfaller <leo@xxxxxxxx> wrote: > > On 2023-11-27 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. > > > > 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. > > > > 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 are also at least two approaches to solve it, I guess: > > 1. Somehow indicate on the command line (via target or a dedicated option) > > to emit the clear cache call for cortex M, and I guess that the function > > itself should do nothing if both caches are disabled. > > 2. Define hooks or provide a command line option so that developers can > > provide an implementation for their platform? > > > > Assuming I were to do this the improper way (and just create a build that > > works only for my particular target): Where should I define > > CLEAR_INSN_CACHE? > > > > I am not sure if there is already a way to do all this that I am just > > unaware of? > > > > Many thanks, > > Ed Robbins > > I have lots of code with nested functions. When switching to gcc-12 I got random > crashes on my cortex-m7 targets. In order to get that working again I had to patch > gcc/config/arm/arm.h: > > --- ../orig/gcc/config/arm/arm.h > +++ ./gcc/config/arm/arm.h > @@ -2518,4 +2518,7 @@ > representation for SHF_ARM_PURECODE in GCC. */ > #define SECTION_ARM_PURECODE SECTION_MACH_DEP > > +#if !defined CLEAR_INSN_CACHE > +#define CLEAR_INSN_CACHE(BEG, END) > +#endif > #endif /* ! GCC_ARM_H */ > > In addition to that I have implemented __clear_cache in the attached file. Without > the gcc patch __clear_cache is not getting called by gcc. All this will work only, > when you operate the data cache in write through mode. But when you are using dma, > this is pretty much mandatory because otherwise you have to maintain dma-memory > completely separate from your data/bss segment. I think write back is pretty much > useless on the m7. We are using an atsame70. > Thanks very much Mathias! This is roughly what I thought was required, and should enable me to get nested functions working. I think that you can use DMA with write back caching if you flush the data cache before starting DMA (if the source is memory) and invalidate the data cache when DMA is finished (if the destination is memory). Of course, this has a performance impact... I think that it would be good if gcc provided a way to handle this for bare metal targets where it is relevant, perhaps by giving an option that names the clear_cache function (-mclear-cache-func=f, or something). I believe the MIPS target has -mflush-func= for this or a similar purpose. We are also using atsame70, as well as s70/v70/v71 (when chips were scarce we re-designed the product to use an LCC plate so we can use any of these in any package, as long as they have sufficient RAM/flash). Best regards, Ed
