Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2015-03-18 at 23:45 +0000, Joseph Myers wrote:
> It's come to my attention that in fact my patch does not fix the bug for 
> 32-bit x86, since that has its own lowlevellock-futex.h which does not 
> define lll_futex_timed_wait_bitset.
> 
> The reason 32-bit x86 cannot use the generic Linux lowlevellock-futex.h 
> (at least, as stated in 
> <https://sourceware.org/ml/libc-alpha/2014-12/msg00666.html>) is 
> unavailability of six-argument syscalls from C.  The sixth syscall 
> argument goes in %ebp (the frame pointer), leaving no general-purpose 
> registers other than %esp free at the time of the syscall.
> 
> The effect is that using a six-argument syscall from C would require the 
> frame pointer to be eliminated in any function using such a syscall, as 
> well as requiring the compiler to handle an inline asm that leaves no 
> registers free other than the stack pointer.
> 
> It is or was also the case that asms clobbering the hard frame pointer do 
> not work with GCC; this resulted in problems for Thumb-2 glibc.  
> Furthermore, if you make the asms save and restore the frame pointer 
> internally (necessarily on the stack in the x86 case, given the lack of 
> other registers), you need to represent this in CFI.
> 
> The problem with representing frame pointer save and restore resulted in 
> Thumb-2 glibc using out-of-line syscalls; see 
> <https://sourceware.org/ml/libc-ports/2010-04/msg00001.html>.  With DWARF 
> it should be possible to represent "at this point, the CFA is derived in 
> this way from the value saved in this stack location".  It's not clear to 
> me, however, how that could be done in an inline asm in such a way to work 
> with whatever choice the compiler has made for the CFA for that function 
> (which might be based on either %ebp or %esp, at an offset unknown to the 
> inline asm) - normal register saves and restores inside inline asm are 
> fine, saving %ebp on the stack may be harder.
> 
> So it seems natural to me for six-argument syscalls to use an out-of-line 
> helper on x86, as for Thumb-2.  Which options would people prefer?
> 
> For how the helper is defined:
> 
> * Some way I haven't thought of to keep the syscalls inline while having 
> accurate CFI.
> 
> * Out-of-line in libc, normal calling convention.
> 
> * Out-of-line in libpthread only (given the current need for such syscalls 
> only in libpthread), normal calling convention.
> 
> * Out-of-line in libpthread only, special calling convention.

I have no strong opinion; the latter two or three seem alright to me.

> For how it is used:
> 
> * Used in some way by the INTERNAL_SYSCALL macro for the six-argument 
> case.
> 
> * Used only by some special macro in lowlevellock-futex.h.

Both would work I guess, and the latter could be easier, or not?

> For how large the initial fix is:
> 
> * Implement only lll_futex_timed_wait_bitset with the new facility, 
> deferring other futex features until there is some known case for them.
> 
> * Completely move to the generic lowlevellock-futex.h (implies making 
> INTERNAL_SYSCALL handle the six-argument case).

It would be nice if the generic lowlevellock-futex.h could support all
futex operations on all archs (provided the respective kernel supports
them there etc.).  I'm not sure whether this implies handling it in
INTERNAL_SYSCALL; couldn't you also use something custom to
lowlevellock-futex.h?

The other 6-argument users are lll_futex_requeue,
lll_futex_cmp_requeue_pi, and lll_futex_wake_unlock, all of which are
used in the existing condvar implementation AFAIR.  The new
implementation I have posted doesn't use them, but this might change
depending on which feedback I get for the PI support, and whether we
choose to use the requeue optimization or not.  We could use those futex
operations in the new condvar only if they were available (and accept
potentially degraded features/performance if not), but it could also be
nice if the operatiosn would just always be available.