"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
I'm not sure that you mean by pipe(2) and pipe(3), but according to my man
page, pipe should return with EFAULT in this case.
EMFILE Too many file descriptors are in use by the pro
ENFILE The system file table is full.
EFAULT filedes is not valid.
> > 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: firstname.lastname@example.org, PGP key available +
_ _ ____ ___ Carsten Langgaard Mailto:email@example.com
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556