From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10796 invoked by alias); 18 Jul 2006 07:24:49 -0000 Received: (qmail 10779 invoked by uid 22791); 18 Jul 2006 07:24:47 -0000 X-Spam-Check-By: sourceware.org Received: from ns2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Jul 2006 07:24:44 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id D8A3C1EC6F; Tue, 18 Jul 2006 09:24:40 +0200 (CEST) From: Andreas Jaeger To: Mark Kettenis Cc: gdb@sourceware.org, libc-alpha@sourceware.org, ak@suse.de Subject: Re: Notes on a frame_unwind_address_in_block problem References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> <8340.192.87.1.22.1153121386.squirrel@webmail.xs4all.nl> <20060717131527.GA9392@nevyn.them.org> OpenPGP: id=C272A126; url=http://www.suse.de/~aj/keys.txt Date: Tue, 18 Jul 2006 09:48:00 -0000 In-Reply-To: <20060717131527.GA9392@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 17 Jul 2006 09:15:27 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" 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/msg00125.txt.bz2 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 2050 Daniel Jacobowitz 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 =3D act->sa_handler; > memcpy (&kact.sa_mask, &act->sa_mask, sizeof (sigset_t)); > kact.sa_flags =3D act->sa_flags | SA_RESTORER; > > kact.sa_restorer =3D &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) =3D=3D 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 statement= s. > > Either way seems reasonable. Andreas --=20 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GPG fingerprint =3D 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 --=-=-= Content-Type: application/pgp-signature Content-length: 188 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEvIy3OJpWPMJyoSYRAuteAJ9FEVsLuxkG2DO7k0bS95wY7HQ1TQCfQwW/ Jco2Tg97KowC4t0xf7H1GHk= =o9aI -----END PGP SIGNATURE----- --=-=-=--