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 +
