From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11499 invoked by alias); 23 Aug 2013 06:54:04 -0000 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 Received: (qmail 11485 invoked by uid 89); 23 Aug 2013 06:54:03 -0000 X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.2 Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 23 Aug 2013 06:53:30 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 81807265DB64; Fri, 23 Aug 2013 08:53:28 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYeejvPzD88n; Fri, 23 Aug 2013 08:53:28 +0200 (CEST) Received: from [192.168.0.12] (mtg95-3-82-238-192-125.fbx.proxad.net [82.238.192.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 40F81265BCFD; Fri, 23 Aug 2013 08:53:27 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [PATCH v3] Windows x64 SEH unwinder From: Tristan Gingold In-Reply-To: <52163929.1090008@redhat.com> Date: Fri, 23 Aug 2013 06:54:00 -0000 Cc: "gdb-patches@sourceware.org ml" , Joel Brobecker , Roland Schwingel Content-Transfer-Encoding: 7bit Message-Id: <9FD66EEA-C685-4F32-8F91-F9E0FF6AAAEE@adacore.com> 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> <66611BA9-4536-42B2-A65C-4EA5DA219E22@adacore.com> <50EEEB3C.9050202@redhat.com> <5BE11EDB-7832-4489-8CB1-6382F5D1D34E@adacore.com> <51F29440.3030808@redhat.com> <6F12353E-D32C-40F0-87BF-AA77FC15BE03@adacore.com> <52162DA9.5060108@redhat.com> <848C81AC-2171-412B-A6F2-101352933F3E@adacore.com> <52163929.1090008@redhat.com> To: Pedro Alves X-SW-Source: 2013-08/txt/msg00663.txt.bz2 On Aug 22, 2013, at 6:15 PM, Pedro Alves wrote: > On 08/22/2013 04:41 PM, Tristan Gingold wrote: >> >> On Aug 22, 2013, at 5:26 PM, Pedro Alves wrote: >> >>> On 08/22/2013 10:33 AM, Tristan Gingold wrote: >>>> >>>> after discussion with Roland Schwingel, I have found that the patch >>>> doesn't handle well dwarf3 DW_OP_call_frame_cfa, because the SEH >>>> unwinder is before the dwarf2 one. >>> >>> Can you clarify this a little better for the archives? >> >> Sure. >> >>> So that mean that for binaries built before that gcc fix, >>> the SEH unwinder won't kick in at all, right? >> >> No. >> If dwarf2 info are presents, they will be used to unwind the >> frames. If they aren't, unwinding will probably fail. > > Okay, I ISTR now that the SEH unwinder needs to always kicks > in, as leaf frames are identified by absence of SEH... So on > old binaries without SEH and without dwarf, the SEH unwinder > will kick in, but the SEH unwinder will probably think all > functions are leaf, and that naturally most probably fails. Correct. But it should be roughly as good as without the SEH unwinder. > Good, now we have somewhere archived to point people at > once someone complains. :-) > >> >>> Then, >>> how come this fixes Roland's age old issue, and improves >>> unwinding for him? >> >> For the part compiled with gcc, the patch shouldn't change >> anything. But for function compiled by MS compilers (those >> in dll), gdb will now unwind their frame by using the SEH >> unwinder, > > Got it. > >> >>> In the previous versions, there was talk about needing >>> finer ordering of the unwinders in order to support both >>> old and new binaries. What changed? Why is this okay >>> now? >> >> Unwinding was possible when compiled with -g. It is still >> possible. >> Version 1 and 2 of the patch failed, because the dwarf >> unwinder was never used (always masked by the SEH unwinder). > > I understand that, but what I'm asking is about this discussion > in v2: > > http://sourceware.org/ml/gdb-patches/2013-01/msg00185.html > > On Jan 9, 2013, at 6:10 PM, Pedro Alves wrote: >> On 01/09/2013 04:28 PM, Tristan Gingold wrote: >> >>>>> I don't really see a real way of supporting both old and new versions >>>>> of GCC, unless we have a way of more finely ordering the unwinders. >>>> >>>> What specific finer order where you considering would be needed to >>>> fix this? >>> >>> Joel once proposed to activate this unwinder if the CU is compiled >>> by gcc 4.6 or older. >> >> I don't think you need to have a way of more finely ordering >> the unwinders for that. AFAICS, we can make the sniffer >> return false in that case. I had understood him >> as meaning something about making the whole prepend/append >> mechanisms more finer grained somehow. > > So coming from that angle, and seeing that v3 just uses the > usual prepend/append mechanisms, I naturally get curious on > whether we're missing something now. > > So IIUC, this new ordering means that even for objects > compiled with newer gcc's that emit SEH, as long as there's > dwarf debug info, then GDB won't use the SEH to unwind. Correct. > I'm guessing that using SEH if available would > be better over dwarf2 (though I don't know for sure). Why ? I think that both unwinders should be correct. One might be faster than the other, but I don't know which. > And, this version is then a compromise. Right? The only compromise is when there are no unwind infos. Previously a default unwinder based on heuristic was used (doesn't work well, particularly for MS dll). With the patch, they are considered as leaf functions by the SEH unwinder. > Just trying to understand, and record all this info > somewhere, not pushing to have it fixed. Sure. No problem with that. >> It is still possible that gdb with support for SEH unwinder >> fails where gdb without for binaries produced by old gcc for >> the cases where the prologue analyzer using heuristic was >> correct. But debugging with this unwinder isn't reliable. > >> >> Hopes it clarifies :-) > > Thanks, it does, somewhat. :-) Tristan.