I'd be interested in hearing ideas of how to fix this properly.

PR has more information.  Essentially the symptom is that certain
programs "hang" in infinite TLB miss on startup b/c executing their
.init section triggers the condition.

On Thu, Aug 24, 2006 at 03:34:25 +0400, Valeriy E. Ushakov wrote:

> On Thu, Aug 24, 2006 at 00:02:33 +0900, Izumi Tsutsui wrote:
> 
> > I'm not familiar with SH, but it looks VIPT
> > (virtually indexed and physical tagged) cache
> > handling problem, which is also annoying on mips.
> 
> Yes, that's it.  I wrote a small self-contained testcase to reproduce
> this bug that basicly does:
> 
> 	func[] = { binary code for: mov.l @r4, r0; rts; nop; }
> 
> 	write(fd, func);
> 	code = mmap(fd, RX);
> 	data = mmap(fd, RW);
> 
> 	if (show how to avoid the bug)
>             *(uint32_t*)data = *(uint32_t*)code;
>             // breakpoint does that by writing to the code page
> 
> 	(*code)(data);  // stuck
> 
> 
> > Maybe we should check virtual cache index in pmap_pv_enter() and
> > allow multiple mappings if VA pages being mapped have the same
> > virtual indexes like mips pmap?
> 
> My reading of Schimmel's book sections 2.2.5 and 3.3.6 is that for
> that to work the cache must use write-allocate so that if we write via
> one alias, we cause the line to be loaded into the cache so that
> references via the other alias pick up the change.  We run SH4 in
> write-through (w/out write-allocate) mode by default, so we cannot use
> those less strict aliasing rules or add logic to check that both
> aliased mappings are read-only (but I'm not sure if the added
> complexity in the TLB miss processing path makes it worthwhile).
> 
> 
> > Or mapping the pages uncached?
> 
> That would work but that would also hurt performance.
> 
> 
> > Or MI VM (or ld.elf_so) should be fixed to avoid such mappings?
> 
> Let's see.  The bug we are trying to avoid is when a single
> instruction needs both aliases mapped by the TLB.  In SH3 ISA that can
> only happen if one reference is the instruction fetch and the other is
> the operand of that instruction.  We should be able to detect that
> situation when we create a would-be alias and force a copy to avoid
> aliasing.  There still will be a corner case of aliases that are
> shared writable and executable mappings, but I'm not sure we care
> about those in practice :).
> 
> A quick and minimal fix (as far as we are concerned with parctical
> aspects and not theroretical correctness over all possible situations)
> would be to tweak ld.so to force COW for the aliased pages after
> mapping the object into memory.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen