Re: Notes on a frame_unwind_address_in_block problem

[Andreas Jaeger <aj@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Daniel Jacobowitz <drow@false.org> writes:

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

i386 is the only platform doing it.  I don't know the history of the
change and whether this is the right thing to do.  Is somebody willing
to test this?

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

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]