Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 19 Mar 2015, Roland McGrath wrote:

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

As I understand it, you'd need to have a separate frame for the asm like 
that - otherwise the asm doesn't know whether to describe the saves of 
each register or not (if the containing function had in fact already saved 
a register to use it for something else, it would be incorrect for the asm 
to describe its own save in CFI unless the asm has its own frame - and, 
the asm can have CFI to describe where its "return address" is, but not to 
describe where the function's return address is, so the function's own CFI 
for that must remain valid).

It's not clear to me that having an extra frame show in the debugger when 
there isn't actually a separate function involved would be particularly 
desirable for users, however.

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

Note the several libc-do-syscall additions currently needed in 
sysdeps/unix/sysv/linux/arm/Makefile - though I think for x86 it should 
just be libpthread that needs this at present.

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

I don't think a fully optimal sequence can be achieved, whether inline or 
out of line.

Ideally you'd simply describe all the arguments to the asm and have the 
compiler move them into place.  But that's what we can't do (have an asm 
use every register except %esp) that requires more complicated tricks in 
the first place.  You can't describe "call using as many registers as 
possible with remaining arguments on the stack" because asm constraints 
can't, I think, say "put these arguments in this order at the top of the 
stack".  That means that when doing an out-of-line call, you lose a 
register in order to pass the address where the remaining arguments are 
located.  But you have the same issue with putting arguments on the stack 
in C code and then extracting into registers inside the asm if you do 
things fully inline.  And if you use memory operands to the asm (as the 
existing asms do to provide somewhere to save %ebx for five-argument 
syscalls for PIC), it's possible those memory operands will have addresses 
based on %ebp - requiring extra care not to use them after %ebp has been 
modified to contain a syscall argument.

So my inclination would be an out-of-line function with five register 
arguments (leaving %ebx, %ebp, %esp free in the caller, though in 
principle for non-PIC code only two registers would need to be left free), 
with the first four arguments being the syscall number and three of the 
syscall arguments the last of those function arguments being used to pass 
the stack address at which the remaining three syscall arguments are 
locations.

-- 
Joseph S. Myers
joseph@codesourcery.com