From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7478 invoked by alias); 17 Jul 2006 13:15:43 -0000 Received: (qmail 7461 invoked by uid 22791); 17 Jul 2006 13:15:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 17 Jul 2006 13:15:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G2SwZ-0002Tg-JO; Mon, 17 Jul 2006 09:15:27 -0400 Date: Mon, 17 Jul 2006 13:20:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: Andreas Jaeger , gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Notes on a frame_unwind_address_in_block problem Message-ID: <20060717131527.GA9392@nevyn.them.org> Mail-Followup-To: Mark Kettenis , Andreas Jaeger , gdb@sourceware.org, libc-alpha@sourceware.org References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> <8340.192.87.1.22.1153121386.squirrel@webmail.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8340.192.87.1.22.1153121386.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00113.txt.bz2 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