Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations)

[Camm Maguire]

Greetings, and thanks for making this so clear!

Indeed, this does appear to be what the sequence Daniel suggested so
successfully for ppc does:

#define CLEAR_CACHE do {void 
*v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; for (;v<ve;v+=32)   asm 
__volatile__ ("dcbst 0,%0\n\tsync\n\ticbi 0,%0\n\tsync\n\tisync": : "r" (v) : 
"memory");} while(0)

So I guess what I need to do is to try to collect the analogous
instructions on the other Debian architectures if possible.

Philip and Andreas, the revisiion you so helpfully suggested for arm
alas still does not work, with the same symptoms.  Can you please
point me to the arm versions if any of 'sync', i-cache invalidate, and
nop?

Paul, it sounds like you know MIPS.  What about here?

Thanks!
 

Paul Koning <address@hidden> writes:

> Camm,
> 
> Offline, because I'm not sure I have the context of your question and
> don't want to publicly divert it to random places...
> 
> Are you dealing with loading executable code, and fighting the cache
> for that to work right?
> 
> For a typical modern CPU, you need logic like this: 
> 
> 1. flush the D-cache
> 2. memory barrier ("sync", whatever it's called) to make sure those
>    writes are finished.
> 3. invalidate the I-cache
> 4. some NOPs to make sure nothing that was in the I-cache is already
>    in the fetch pipe
> 
> and only then can you safely execute code that was written to "memory"
> before step 1.
> 
> I have no idea how that translates to things you would do with system
> service calls in an OS, which I think is what the current discussion
> is about.  But, for example, on MIPS the above sequence is what has to
> happen when you get down to the hardware level.
> 
>        paul
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah