patch #4 (Re: patch #3 (Re: The time has come for a kernel interfacing library layer))

[Joerg Sonnenberger]

On Thu, May 12, 2005 at 10:03:24AM -0700, Matthew Dillon wrote:
> 
> :But we don't return 64bit values. Only 32 bit. Why can't it simply return
> :errno in one register and the normal return value in the other? It would
> :save the whole carry register dance.
> 
>     We sure do return 64 bit values!  lseek().

I only checked the normal definition, sorry. Yeah, this is a problem.

> :>     translated system call might require more arguments.  For another,
> :>     some sort of conversion is already going to have to be done and the
> :>     cost of copying a couple of 32 bit ints becomes zip relative to the
> :>     other work that must occur.
> :
> :OK, so we depricate the generic syscall?
> 
>     No.  Most system calls won't need translation.  We don't want to have
>     to manually write wrappers for 300 system calls!  A generic syscall
>     generator is still very much necessary.

I meant syscall(2).

> :>     The RTLD could set up a dummy TCB (with *NO* TLS storage attached).
> :>     Poof, problem solved.  That would allow the RTLD to use the same syscall
> :>     layer that the program uses, too.
> :
> :The RTLD would have to do that every time it is called, it would have to
> :reset it before any signal, that's a lot of requirements.
> :This completely ignores the issues of reentrancy in RTLD, of course.
> :
> :Joerg
> 
>     I'm not sure what you mean here.  The RTLD would only need to set up
>     a dummy TCB at init time.  After that there will always be a TCB,
>     either the original dummy one that the RTLD set up, or the one that
>     libc sets up, or pthreads or libthread_xu.  There will always be a TCB,
>     and *ALL* of the TCBs have to use our structural definition for the TCB
>     in order to work at all... not just for errno handling, but simply for
>     TLS support to work as expected.

Yes, but they point to an errno which is not RTLD's errno.

Joerg