Florian Lohoff wrote: > > On Mon, May 21, 2001 at 04:23:52PM -0700, Jun Sun wrote: > > The patch seems to be just a fast implementation of sysmips(). Why would it > > solve an otherwise illegal instruction problem? > > > > George, what was exactly the error and the faulty instruction? > > Wrong - Its not only a "fast" path sysmips. It solves the illegal instruction > case as it carefully doesnt touch registers it should not touch. > > The sysmips illegal instruction stuff came from the early exit > needed to skip the -EXXXX case in the scall32.S which did not > restore the modified registers. This needed fixing and there was > no clean way of doing this in C thus i wrote an asm sysmips/MIPS_ATOMIC_SET > and called it "fast_sysmips" which itself would go into the old > sysmips function when not MIPS_ATOMIC_SET. > I see. I took a look of MIPS ABI in system V and found that the spec only specifies this extended call in C prototype: int _test_and_set(int *p, int v); It seems perfectly legal for us to add one more argument to store the return value while still have the function returns error. Of course, doing that will break binary compatibility. Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary compatibility although it is a little clunky. A third possibility is the have a MIPS_NEW_ATOMIC_SET that take three arguments. If that approach is taken, I would take out the inline assembly that jumps to o32_ret_from_sys_call and documents MIPS_ATOMIC_SET as deprecated and valnerable. My preference, in the decreasing order, is 3), 2) and 1). Ralf, what do you think? We cannot let the bug sit around in the CVS tree for long. Have to have some fix. Jun
