This is the mail archive of the
mailing list for the GDB project.
Re: Notes on a frame_unwind_address_in_block problem
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
struct kernel_sigaction kact, koact;
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
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.