On Tue, 25 Jun 2002, Carsten Langgaard wrote:
> The next LTP failure line is:
> pipe05 1 BROK : Unexpected signal 11 received.
>
> For this one I haven't got a fix, because the failure is due to the way
> the pipe syscall is implemented for MIPS (so we need a fix in both the
> kernel and glibc).
>
> The glibc code look like this
> SYSCALL__ (pipe, 1)
> /* Plop in the two descriptors. */
> sw v0, 0(a0)
> sw v1, 4(a0)
>
> /* Go out with a clean status. */
> move v0, zero
> j ra
> .end __pipe
>
> The problem is that the code is called with $a0 = 0. So the 'sw v0,
> 0(a0)' after the syscall generates a segmentation fault.
The test is broken and it's what should be fixed, instead -- several
Linux platforms do it this way, e.g. Alpha and IA-64. A SIGSEGV is a
valid response for an invalid address. Remember you test pipe(3) and not
pipe(2).
> Why are the pipe syscall implemented this way, where we return the two
> descriptors in v0 and v1 ?
For performance reasons. Also it's safer to do such actions from the
userland.
> Why doesn't the kernel do these stores (this way we can do an access
> check, like i386 does) ?
I suppose i386 does these stores in the kernel due to historical reasons.
There is also the problem of a permanent lack of registers in i386 -- I
haven't investigated it, but it may simply be unable to afford a second
result register.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +