libthr does not obey WITHOUT_SYSCALL_COMPAT

David Xu davidxu at
Sun Mar 8 23:00:08 PDT 2009

Daniel Eischen wrote:
> 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
>>>>> Regards
>>>> Committed!
>>> I never got around to replying to this...
>>> I don't quite understand why __fcntl_compat is there.  We have
>>> 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
>> 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.  ;-)

Yes, it is better to use versioning instead, I don't know why 
fcntl_compat is there without using this feature.

More information about the freebsd-threads mailing list