From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30683 invoked by alias); 9 Jan 2013 19:11:35 -0000 Received: (qmail 30660 invoked by uid 22791); 9 Jan 2013 19:11:34 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,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 19:11:28 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r09JBQPA016260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 14:11:26 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r09JBNCC030210; Wed, 9 Jan 2013 14:11:24 -0500 Message-ID: <50EDC0DB.3090707@redhat.com> Date: Wed, 09 Jan 2013 19:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tom Tromey 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> <871uduz319.fsf@fleche.redhat.com> In-Reply-To: <871uduz319.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00182.txt.bz2 On 01/09/2013 05:20 PM, Tom Tromey wrote: >>>>>> "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. Thanks. I hadn't caught the desire to put bits in before the dwarf unwinder, and other bits after. I re-read the original post, and now I read it as always wanting this unwinder after the DWARF unwinder. (note: "behind" is ambiguous to me). That looks doable with the current architecture, without splitting the new unwinder, by appending the non-checking unwinder in amd64_windows_init_abi before calling amd64_init_abi, and have its sniffer always claim the frame (which it would anyway), so the fallback heuristic's sniffer never gets a chance to run. But I'd guess before or after dwarf doesn't really matter. > 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. Right. The catch-all unwinders are heuristic, and naturally can't always work 100% correctly, worse on non-x64 targets, where we don't have as stiff prologue format requirements. I got confused with the minimal leaf function handling in the patch, but this, coupled with __fastcall makes it clearer: " leaf functions have limitations: Can not call out to other functions Can not change any non-volatile registers Can not change the stack pointer " (It goes without saying, but FAOD, I'd prefer that explanations to my doubts ended up as comments in the code.) > 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. Yeah, it's not obvious. Put a break on dwarf2_append_unwinders. The x86-64 gdbarch initialization starts in i386-tdep.c:i386_gdbarch_init, shared with 32-bit. There's no amd64_gdbarch_init. That is what appends the dwarf unwinders, with the dwarf2_append_unwinders call. At the bottom, this/a gdbarch init function initializes the osabi (e.g., amd64_linux_init_abi), and this is what calls the generic x86-64 amd64_init_abi early on, and installs the prologue-based fallback unwinders. -- Pedro Alves