From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13850 invoked by alias); 9 Jan 2013 16:06:18 -0000 Received: (qmail 13839 invoked by uid 22791); 9 Jan 2013 16:06:15 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Jan 2013 16:06:08 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MGD00L008LJMG00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Wed, 09 Jan 2013 18:05:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGD00LPH8P6J230@a-mtaout23.012.net.il>; Wed, 09 Jan 2013 18:05:30 +0200 (IST) Date: Wed, 09 Jan 2013 16:06:00 -0000 From: Eli Zaretskii Subject: Re: [RFA/commit+doco 2/2] Windows x64 SEH unwinder. In-reply-to: <1357728781-15073-3-git-send-email-brobecker@adacore.com> To: Joel Brobecker Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pq1egx45.fsf@gnu.org> References: <1357728781-15073-1-git-send-email-brobecker@adacore.com> <1357728781-15073-3-git-send-email-brobecker@adacore.com> X-IsSubscribed: yes 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/msg00167.txt.bz2 > From: Joel Brobecker > Cc: Joel Brobecker > Date: Wed, 9 Jan 2013 14:53:01 +0400 > > This is the main part of the patch series, which actually > adds the unwinder. Thanks! > One element worth mentioning, perhaps, is the fact that we prepend > the unwinder, and the sniffer is the default_frame_sniffer which > always returns 1 (absence of SEH info is normal and means it is > a leaf function). This effectively means that all other unwinders > effectively get shunted. And in particular, I do not think that > the DWARF unwinder will kick in even if DWARF unwind info is found. > > The problem is that we want to be ahead of the default amd64-tdep > unwinders, which is kind of a last-resort unwinder doing a good > job under limited situations only. We'd like to be behind the DWARF > unwinder if we could, but I don't think there is a way to ensure > that yet. > > In practice, this shouldn't be a problem, since this unwinder > has been very reliable for us so far. But it does assume that > the compiler is recent enough to generate native SEH data which, > for GCC, means GCC 4.7 (I have been told). On the other hand, > it looks like the first GCC release to support x64-windows was > GCC 4.6. > > 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. > Worse case scenario, we stop supporting code generated by GCC 4.6. > Or an alternative option is to provide a setting to disable this > unwinder. I'm confused: is this change only for 64-bit Windows programs? If not, what GCC versions will this support for debugging 32-bit executables? > diff --git a/gdb/NEWS b/gdb/NEWS > index 3451505..d981ac5 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -134,6 +134,8 @@ show print type typedefs > feature to be enabled. For more information, see: > http://fedoraproject.org/wiki/Features/MiniDebugInfo > > +* GDB can now use Windows x64 unwinding data. > + This is OK to go in, but it seems to imply that only 64-bit executables are affected. What would it take to do the same on 32-bit Windows?