Re: More ARM binutils fuckage

["Martin Guy" <martinwguy at yahoo dot it>]

> > As I understand it, it has to access the
> > code segment with a data-fetch instruction, which refetches the data
> > from RAM through the data cache. I would have thought that invalidates
> > the version of that page cached in the instruction cache to avoid
> > cache conflict, so when the system call returns, the code page gets
> > fetched yet again into the instruction cache.

> In fact, pretty much every ARM out there needs its icache invalidated
> explicitly when code is written to RAM via the dcache.  This is the
> reason we have the sys_cacheflush() system call.

Yes, but we're not writing to the code segment here.
However it looks like it's not as bad as I thought. Quote from Pitre
at http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4
=====
Instead of encoding the syscall number in the swi instruction which
requires reading back the instruction from memory to extract that number
and polluting the data cache, it was decided that simply storing the
syscall number into r7 would be more efficient.
=====
Which suggests that it is happy to have the same page cached in both
the instruction and the data caches at the same time, and that it's
just a question of refetching the item as data and wasting some of the
data cache.

    M

--
For unsubscribe information see http://sourceware.org/lists.html#faq