On Thu, 3 Dec 1998, Charles M. Hannum wrote:

> 
> So the random core dumps did not go away with the kcopy() bug fix.
> But I looked at the 7 core dumps that occured during a `make all' in
> /usr/src, and they all appear to be due to the same problem.
> 
> It appears that occasionally ld.so is not causing the I cache line(s)
> backing a PLT entry to be flushed properly.  What happens in this case
> is that the D cache line with the address (formerly the offset to
> entry 0) now points to the function, but the code at the beginning of
> the PLT entry still adds the address to the pc, rather than just
> jumping to it.  This causes a branch to Somewhere Very Wrong --
> sometimes to a random valid code block, sometimes into an invalid
> page.  It more or less always causes a core dump.
> 
> I'm not yet sure why the cache isn't being synced correctly.
Hi,
  There should not be any I cache sync issues with the PLT's. The very
first iteration of them (pre-dates integration) used to sync each jmpslot
when it was modifed but this was unacceptable from the performance angle. 
As a result the jmpslot code was modified so that only 1 slot (the first)
needs syncing at start up. All other jmpslots indirect via a 32 bit
address thus forcing the jmpslot fixup only to have to modify a piece of
data thus only affecting the D cache and not the I cache.

This has been working fine for a long time now. The SEGV stuff is a recent
behaviour so I don't necessarily thing that it is jmpslot specific.

If you think you can see how the problem arises let me know and we can
work on a solution.

CHeers,
			Mark