[Top] [All Lists]

Re: LTP testing

To: Carsten Langgaard <>
Subject: Re: LTP testing
From: "Maciej W. Rozycki" <>
Date: Tue, 25 Jun 2002 15:53:25 +0200 (MET DST)
Cc: Ralf Baechle <>, "" <>
In-reply-to: <>
Organization: Technical University of Gdansk
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

> 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

> 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:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>