[Sablevm-developer] Instruction cache flush (non)portability

[Grzegorz P. <ga...@de...>]

Hi!

I have spent most of today's day searching for ways
to flush instruction cache in any more portable way,
than writing the "right" assembler for every arch.
Here's what I found out.

There's no exported and usable interface for this in
neither glibc nor gcc nor kernel headers, nor linux
headers (/usr/include/linux, /usr/include/asm).
There were such proposals, but none of them resulted
in anything usable by us.

From our POV we need simply a function
flush_icache_range(void *from, int len),
where len is same as word size for current arch.

However be warned, that this function not that simple
for some architectures and may require kernel function
call for ex. Other problem is that it's sometime cheaper
to clear all of the cache than flushing specific part
(don't ask me, that's what I found in gcc sources).

So if we don't want to implement needed assembler/other
not-that-nice-and-clean things ourselves for every
arch we want to support "inlined" engine on - we have
only one solution (it seems).

We need to link to __clear_cache symbol that comes from
gcc. It's GPL symbol, but with exception for when the usage
of it is because of gcc usage - so we fall under this anyway.

The upside is that we can simply define:
extern void __clear_cache (char *beg, char *end)
and just use it.

The downside is that
- this is internal symbol and as such may be subject to
change w/o prior notoice (not saying anything about backward
compatibility)
- it's only portable across arches where we use gcc (not that
big problem ATM anyway)

It's even more complicated if we link to that symbol and it's
definition changes. On i386 (and most of the arches) we're
_staticly_ linked to libgcc2 library (which contains the symbol).
Thus - we don't have to worry about gcc upgrades etc.
However on some arches, like m68k - or so I was told.

Upside once again:
- I doubt the symbol will change in some dramatical way.
In such case we could either reflect the change in our code
or
- we can always disable "inlined" engine for selected arches
(until a fix/other solution is found) but still support them.

I personally would vote that we use this symbol in one of next
versions, after my old "every arch" patch is applied.

What do you think?

				Grzegorz B. Prokopski