I would vote for option #4 - make sure the ll/sc emulation stuff works
and use ll/sc in glibc instead of sysmips. Beyond the pthreads mutex
stuff in glibc I have yet to come across usage of sysmips. Of course you
still need sys_sysmips to function correctly (in case somebody did a
silly thing like call sysmips directly just for the fun of it), so I
like like Florian's solution. Adding a parameter is a silly thing to do,
and we don't need to be adding functionality to sys_sysmips through
NEW_MO_BETTER_AS_SEEN_ON_TV_ATOMIC_SET or what have you...
Jun Sun wrote:
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 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.
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839