On Tue, Jun 25, 2002 at 03:53:25PM +0200, Maciej W. Rozycki wrote:
> 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
The question is what API spec is relevant for Linux. My pipe(2) man page
says (there is no pipe(3) man page):
int pipe(int filedes);
EFAULT filedes is not valid.
whereas The Single UNIX ® Specification, Version 2
implies the SIGSEGV is OK.
Maybe the LTP folks can shed a light on this.