Re: [PATCH] Add libgcc support for cache clearing on ARM VxWorks

[Olivier Hainque <hainque at adacore dot com>]

Hi Richard,

> I'm not going to object to this patch - it's ok at a GCC level; but I'm
> not sure that architecturally this is going to work.  The implementation
> of cache clearing is very specific to the implementation and I don't
> think it is possible to write a portable single implementation.
> 
> I must admit, that not being a kernel expert, I'm not completely
> familiar with all the details of cache maintenance, but I don't think a
> single sequence like this will work in general.
> 
> Your code seems to focus only on the Data cache clearing.  Documentation
> in extend.texi seems to suggest that __builtin___clear_cache is supposed
> to clear the _instruction_ cache (which may of course involve also
> synchronizing the Dcache to memory first).  Similar comments in md.texi
> refer to the clear_cache instruction pattern flushing the Icache.  Note
> that arm processors of any architecture revision do not automatically
> synchronize I and D caches.
> 
> Before ARMv7 cache maintenance operations were not available in user
> mode (I don't know if vxworks is expected to run only in a privileged mode).
> 
> On a system without caches the instructions will just abort
> 
> I believe that on v7 you also need ISB and DMB operations at the end of
> the sequence.  But such instructions aren't available on older
> architectures.
> 
> I will not object to this being committed (it's your port); but I'd
> strongly recommend that you don't at this stage.

Thanks a lot for your comments, always very appreciated.

I'll discuss the details with the persons who wrote the
function body. It is quite possible that some aspects were
considered and not implemented eventually just because 
we had something that appeared to work after a number of
experiments with the particular hardware+os configurations
we have at hand. I'm sure that the change observably "fixed"
several problems in these configurations. It's a progress
from this perspective, but I can see that maybe some programs
that would have worked in some configurations before now would
abort. It's quite possible that VxWorks doesn't support such
configurations - to be double checked.

I'll see what matter we have or can gather to go at least a
bit further, and I'll get back to you then :)

Thanks again,

Olivier