Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Jul 17, 2006 at 09:29:46AM +0200, Mark Kettenis wrote:
> Something like what's done in the kernel (arch/x86_64/kernel/vsyscall.S).
> Hmm, I wonder why Daniel's box uses the trampoline from libc instead of
> the trampoline in the vsyscall page.

Ah, now, this is a very interesting question.  I'm glad you asked :-)

__libc_sigaction (int sig, const struct sigaction *act, struct
sigaction *oact)
{
  int result;
  struct kernel_sigaction kact, koact;

  if (act)
    {
      kact.k_sa_handler = act->sa_handler;
      memcpy (&kact.sa_mask, &act->sa_mask, sizeof (sigset_t));
      kact.sa_flags = act->sa_flags | SA_RESTORER;

      kact.sa_restorer = &restore_rt;
    }

That's how we end up at the trampoline: through use of SA_RESTORER.
I didn't respond to this earlier because I wanted to find some time to
check whether that was necessary.

Andreas, looking at the i386 version, I guess that using SA_RESTORER
this way is not necessary.  Simply a performance optimization because
the old trampolines (written to the stack) were so slow, or maybe
because they required an executable stack.  i386 has
"if (GLRO(dl_sysinfo_dso) == NULL)" around it.  Can x86_64 do the same
thing?

The existing unwind information would still be wrong, but on systems
with a vDSO it wouldn't matter any more.

> Anyway, if with the current libc, the trampoline provided by the kernel is
> supposed to be used, then it's probably not worth bothering to add CFI
> to libc, and I'd just remove the CFI_STARTPROC and CFI_ENDPROC statements.

Either way seems reasonable.

-- 
Daniel Jacobowitz
CodeSourcery