Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

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

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

Yeah, you're right.  And for it to be interpreted as a separate frame like
that I think it has to have its own FDE.  The assembler doesn't give us any
way to preserve the state of the compiler-generated FDE covering the part
of the function before the asm and restore that into a new FDE that starts
after the asm.

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

I think it's fine.  Current GDB shows fake frames like that for inlined
functions too.

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

Right.  I think it's adequate to just add those as needed in an ad hoc way.
Some comments in the INTERNAL_SYSCALL implementation can advise people to
expect the undefined symbol error at -shared time if the 6-argument case is
newly used in a particular DSO and know what Makefile bit is needed to
resolve the problem.

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

Sure.  The only way it would be fully optimal is if the compiler just did
the right thing.

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

That's exactly what I had in mind.  It's as close to optimal as is feasible
if the syscall number and three arguments go directly into the registers
where the kernel wants them.  That means they would not be the first three
arguments (since %ebx is first), but that should be fine.


Thanks,
Roland