From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24271 invoked by alias); 23 Mar 2010 11:22:55 -0000 Received: (qmail 24263 invoked by uid 22791); 23 Mar 2010 11:22:54 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Mar 2010 11:22:47 +0000 Received: (qmail 24031 invoked from network); 23 Mar 2010 11:22:45 -0000 Received: from unknown (HELO dirichlet.schwinge.homeip.net) (thomas@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Mar 2010 11:22:45 -0000 From: Thomas Schwinge To: gdb@sourceware.org Cc: dan@codesourcery.com Subject: Re: Ordering of unwinders References: <87r5ncbf2l.fsf@dirichlet.schwinge.homeip.net> Date: Tue, 23 Mar 2010 11:22:00 -0000 In-Reply-To: <87r5ncbf2l.fsf@dirichlet.schwinge.homeip.net> (Thomas Schwinge's message of "Mon, 22 Mar 2010 15:34:26 +0100") Message-ID: <87pr2v8epx.fsf@dirichlet.schwinge.homeip.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (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-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00187.txt.bz2 --=-=-= Content-length: 2627 Hello! On 2010-03-22 14:34, I wrote: > GDB on ARM Linux (arm-linux-tdep.c) -- and, from a quick glance, a bunch > of other architectures do similar things -- currently has the following > series of unwinders configured. These are tried in turn until the first > one succeeds. > > arm_linux_restart_syscall_tramp_frame > arm_eabi_linux_rt_sigreturn_tramp_frame > arm_eabi_linux_sigreturn_tramp_frame > arm_linux_rt_sigreturn_tramp_frame > arm_linux_sigreturn_tramp_frame > arm_stub_unwind > dwarf2_frame_unwind > dwarf2_signal_frame_unwind > arm_prologue_unwind > > I'm working on having proper DWARF CFI in glibc for sigreturn frames -- > but that information is never going to be used, as the DWARF unwinders > are of lower priority than the tramp_frame sniffers. What's the reason? > > Some weeks ago, I had a quick chat with Dan J. about this issue. He > couldn't immediatelly think of a reason why the stub one is in front of > the DWARF unwinders. Also, he suggested that the tramp_frame sniffers > should be moved down, so that the DWARF unwinders are on top of the list. > > Technically, the tramp_frame unwinders are on the top of the list, > because they use tramp_frame_*prepend*_unwinder for registering in > arm-linux-tdep.c:arm_linux_init_abi. tramp_frame_append_unwinder doesn't > exist (not yet -- this could be changed easily, of course). > > The ordering of the five tramp_frame unwinders doesn't matter, correct? > > What to do about arm_stub_unwind -- move it after the DWARF ones? I guess I understand this a bit better now, the description of frame-unwind.h:frame_unwind_prepend_unwinder gives a broad hint: ``Register a frame unwinder, _prepending_ it to the front of the search list (so it is sniffed before previously registered unwinders). By using a prepend, later calls can install unwinders that override earlier calls. This allows, for instance, an OSABI to install a a more specific sigtramp unwinder that overrides the traditional brute-force unwinder.'' Thus, the tramp_frame unwinders should indeed be placed in front of other *_sniff_and_guess unwinders. But where should the DWARF ones be in this game? Unconditionally in front of all the ``sniffing / guessing'' unwinders? This could be done by adding another category between frame_unwind.c's dummy_frame_unwind / inline_frame_unwind, and the osabi_head. Might this be what we should do? Is it feasible for all GDB configurations? That new middle category would probably also contain the libunwind unwinder (and similar ones), but I have no actual experience with that. Regards, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 196 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuopHoACgkQC9ZuxbdEiFi6OgCg5x5RJVGzCLN/mhF5UckmZs76 yJkAn1kZPqi1BngBe9ASEOuiyF270MTC =Ys8D -----END PGP SIGNATURE----- --=-=-=--