From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18586 invoked by alias); 15 Dec 2010 23:07:36 -0000 Received: (qmail 18577 invoked by uid 22791); 15 Dec 2010 23:07:35 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Dec 2010 23:07:29 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id oBFN71Hs023833; Thu, 16 Dec 2010 00:07:01 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id oBFN6x6N019463; Thu, 16 Dec 2010 00:06:59 +0100 (CET) Date: Wed, 15 Dec 2010 23:07:00 -0000 Message-Id: <201012152306.oBFN6x6N019463@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org In-reply-to: <20101214070535.GO2596@adacore.com> (message from Joel Brobecker on Tue, 14 Dec 2010 11:05:35 +0400) Subject: Re: [RFC] Improve amd64 prologue analysis References: <001701cb84ea$6883c170$398b4450$@muller@ics-cnrs.unistra.fr> <20101118172209.GE2634@adacore.com> <004201cb87c1$dab95cd0$902c1670$@muller@ics-cnrs.unistra.fr> <20101119172011.GI2634@adacore.com> <000901cb883c$067a8860$136f9920$@muller@ics-cnrs.unistra.fr> <20101214070535.GO2596@adacore.com> 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/msg00328.txt.bz2 > Date: Tue, 14 Dec 2010 11:05:35 +0400 > From: Joel Brobecker > > 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? Many years ago we realized that prologue analyzers are a dead end. Compilers will continue to invent silly new ways to set up a stack frame and save registers, and we'll forever play catch up. Then amd64 showed up and the folks who designed the ABI actually had the insight to make unwind information pretty much mandatory. As a result we survived very well without an amd64 prologue analyzer. I hope you'll understand my reluctance to add one after managing 7 years or so without. So if support for pdata/xdata gets added I would expect that the prologue analyzer won't be needed on 64-bit Windows either. At that point the prologue analyzer will become dead code and we should remove it again. By not adding the prologue analyzer to other platforms we'll increase the chance that will indeed be possible. The fact that this is for a an OS that in my view should never have been supported by GDB, that has a 64-bit ABI that I consider horribly broken doesn't help. If you stick it somewhere where I don't need to look at it, I won't care as much.