Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

[Roland McGrath <roland at hack dot frob dot com>]

> 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.

You don't need the CFA to express the location where %ebp is saved.  You
can express it directly as register-relative using DW_CFA_expression
(without reference to the CFA).  The assembler doesn't offer any help, so
it would have to be encoded by hand using .cfi_escape.  But it's doable.

However, that indeed doesn't help with making CFA-relative rules come
out correct if the compiler chose to define the CFA itself using %ebp.
But do you actually need to refer to that CFA at all?  In this instance
the one inline asm touches every register.  So it could save and restore
all the callee-saves registers by hand, and give them CFI that describes
each as directly relative to %esp (using DW_CFA_expression).  Or it
could use .cfi_remember_state/.cfi_restore_state around a fresh
definition of the CFA based on %esp and use simple .cfi_rel_offset for
all the other registers.  That would not necessarily yield the same CFA
(I mean the actual value computed at runtime, not the rule) as the
compiler is using in the rest of the function.  But that does not have
to matter.  A debugger might see them as two distinct frames, but that
can be made kosher enough by giving the asm frame a rule to unwind the
PC to its value at the end of the sequence (pseudo-caller as in a
pseudo-frame for an inline).

> * Some way I haven't thought of to keep the syscalls inline while having 
> accurate CFI.

I've sketched out some possibilities above.  I'm not at all sure it's
actually viable or that the code to do it would be the most desireable
code.  But I think it's worth some effort to investigate it concretely.

> * 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.

If it's out of line then I think it should be made directly available in
each library that needs it.  Going through a PLT for this is worse for
performance than just making it a vanilla stub (e.g. PSEUDO_ERRVAL) and
copying args to/from the stack.

We should minimize the overhead of using the helper as much as possible,
which probably means a bespoke mostly-registers convention.

> * Used in some way by the INTERNAL_SYSCALL macro for the six-argument 
> case.

We should do this.

> 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).

The latter is where we want to get to.  I don't have a particular
opinion about getting there more or less incrementally.


Thanks,
Roland