From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18038 invoked by alias); 14 Dec 2010 09:58:04 -0000 Received: (qmail 18030 invoked by uid 22791); 14 Dec 2010 09:58:03 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD 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, 14 Dec 2010 09:57:57 +0000 Received: (qmail 13948 invoked from network); 14 Dec 2010 09:57:55 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Dec 2010 09:57:55 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] Improve amd64 prologue analysis Date: Tue, 14 Dec 2010 09:58:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: Joel Brobecker , kettenis@gnu.org, Pierre Muller References: <001701cb84ea$6883c170$398b4450$@muller@ics-cnrs.unistra.fr> <000901cb883c$067a8860$136f9920$@muller@ics-cnrs.unistra.fr> <20101214070535.GO2596@adacore.com> In-Reply-To: <20101214070535.GO2596@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012140957.53727.pedro@codesourcery.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: 2010-12/txt/msg00223.txt.bz2 On Tuesday 14 December 2010 07:05:35, Joel Brobecker wrote: > Hi Mark, > > > I think that your code does indeed catch some > > instructions that are not covered by my patch, > > especially in Windows DLL. > > If Pierre were to submit a patch that merges both our changes, > do you think it would have a chance of being included? > > The alternative is to start working on a pdata/xdata unwinder, > but I don't see myself having the time to look into that anytime > soon (not within the next 12 months). > > You mentioned that, if we have prologue instruction parsers, they should > be Windows-specific. But I would think that this extra level of > precaution is unnecessary, since the prologue analyzer should almost > never be used on the other platforms where we have the DWARF frame info. > Is that wishful thinking? I imagine that for Wine debugging, table based SEH unwinding in linux code will be useful. -- Pedro Alves