[patch] Fix MIPS pipe, brk

Joakim Tjernlund joakim.tjernlund at transmode.se
Mon Jan 9 15:26:29 UTC 2006


> 
> > Well, its better than hardcoding errno accesses directly in 
> the syscall
> > asm files, but the whole idea with the current impl. of 
> __syscall_error
> > in plain C it to hide and simply the errno handling for asm 
> code. The
> > current MIPS impl. of __syscall_error in NPTL will break as soon as
> > something changes w.r.t errno impl.
> > 
> Then we will fix it until all the thread models and the non-threaded
> case work properly. I did not say it was perfect. I was looking for
> people to actually test it on the linuxthreads model as well as the
> non-threaded case. Volunteers?

Sorry, can't test NPTL.

> 
> > I think you should go back to the C version of __syscall_error if
> > possible. I never understood why it didn't work for MIPS. Will the
> > current C version of __syscall_error break for other arches when TLS
> > is added?
> > 
> The libpthreads for NPTL will not link with the current implementation
> due to __syscall_error being hidden. My reasoning was two-fold. First,
> I wanted to use the same implementation, and in IMHO, the more correct
> way of handling __syscall_error. Second, it allowed me to include the
> file into my libpthread build. However, I could do the same with the C
> function too I suppose.

I don't follow you quite here, what is the more correct way? If you need
to 
call __syscall_error in pthread then you must either unhide it or
include a
copy of __syscall_error in pthread.
None of the above requires an assembly version of __syscall_error.

After looking a bit harder at NPTL I think that some of the breakage
comes from 
using __syscall_error() in linux/mips/sysdep.h instead
of __set_errno().

 Jocke



More information about the uClibc mailing list