From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9229 invoked by alias); 9 Jan 2013 17:53:20 -0000 Received: (qmail 9219 invoked by uid 22791); 9 Jan 2013 17:53:17 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Jan 2013 17:53:12 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r09Hr8i6011603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 12:53:10 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r09HKY79004240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Jan 2013 12:20:49 -0500 From: Tom Tromey To: Pedro Alves Cc: Tristan Gingold , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [RFA/commit+doco 2/2] Windows x64 SEH unwinder. References: <1357728781-15073-1-git-send-email-brobecker@adacore.com> <1357728781-15073-3-git-send-email-brobecker@adacore.com> <50ED9221.1050504@redhat.com> <9E84DF2D-7AF8-4AA1-A5DF-171EF189A6E7@adacore.com> <50EDA48E.2030406@redhat.com> Date: Wed, 09 Jan 2013 17:53:00 -0000 In-Reply-To: <50EDA48E.2030406@redhat.com> (Pedro Alves's message of "Wed, 09 Jan 2013 17:10:38 +0000") Message-ID: <871uduz319.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00177.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I don't think you need to have a way of more finely ordering Pedro> the unwinders for that. AFAICS, we can make the sniffer Pedro> return false in that case. I had understood him Pedro> as meaning something about making the whole prepend/append Pedro> mechanisms more finer grained somehow. FWIW I think Joel explained it in the original post. My understanding based on that is that the absence of SEH is normal, but they'd still like to use this unwinder for such frames, because amd64-tdep.c provides a catch-all unwinder (I guess amd64_frame_unwind) that is not always good enough. It seems to me that there are various possibilities for fixing the problem though. For example, the new unwinder could be split into two parts: one which checks for SEH and one which does not; then arrange somehow for the checking variant to come before the DWARF unwinders, and arrange for the non-checking one to come later; and perhaps change amd64_init_abi so that the Windows code can request that the unwinder-of-last-resort not be installed. I don't know the mechanics of arranging the ordering with the DWARF unwinders. I couldn't actually figure out how these are installed for x86-64. Tom