This is the mail archive of the
mailing list for the glibc project.
Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>, <triegel at redhat dot com>, <carlos at redhat dot com>
- Date: Fri, 20 Mar 2015 02:29:10 +0000
- Subject: Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1503180027220 dot 9536 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1503182310510 dot 14558 at digraph dot polyomino dot org dot uk> <20150319203207 dot 14C692C3B38 at topped-with-meat 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
Joseph S. Myers