libthr does not obey WITHOUT_SYSCALL_COMPAT

[Daniel Eischen]

On Mon, 9 Mar 2009, David Xu wrote:

> Daniel Eischen wrote:
>> On Mon, 9 Mar 2009, David Xu wrote:
>> 
>>> Pawel Worach wrote:
>>>> Hi,
>>>> 
>>>> If libc is built using WITHOUT_SYSCALL_COMPAT applications linked with
>>>> libthr end up having unresolved symbols since libthr references
>>>> __fcntl_compat unconditionally.
>>>> Here is a patch to make libthr also obey WITHOUT_SYSCALL_COMPAT
>>>> http://www.vlakno.cz/~pwo/libthr.diff
>>>> 
>>>> Regards
>>> 
>>> Committed!
>> 
>> I never got around to replying to this...
>> 
>> I don't quite understand why __fcntl_compat is there.  We have
>> F_GETFD, F_SETFD, F_DUPFD, F_DUP2FD, F_GETFL, F_SETFL, F_GETOWN,
>> and F_SETOWN according to fcntl(2).  But thr_syscalls.c only
>> handles F_DUPFD, F_SETFD, F_SETFL, F_GETFD, and F_GETFL, leaving
>> F_DUP2FD, F_GETOWN, and F_SETOWN to be handled by the default
>> case.  And the default case does nothing now if WITHOUT_SYSCALL_COMPAT
>> is defined.  So how do F_DUP2FD, F_GETOWN, and F_SETOWN get
>> handled?
>> 
>> Do we really need to call __sys_fcntl_compat() from libthr?
>> When did the ABI change, before or after libc.so.7?
>> 
>
> I don't know when it appeared. Would this patch eliminate the shit ?

I think so.  But I think for future ABI changes to cancellation
points, wouldn't we need syscall wrappers in libc?  Reason, libc
and libthr are now symbol-versioned, so there will no longer be
library bumps for ABI changes.  But if a syscall is a cancellation
point and libthr has to play games with it, like fcntl, I think
there should be a wrapper around it in libc.  If the ABI changes,
then both libc and libthr would need to provide a compat version
for it.  I think.  ;-)

-- 
DE