From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11908 invoked by alias); 8 Aug 2004 19:28:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11888 invoked from network); 8 Aug 2004 19:28:33 -0000 Received: from unknown (HELO aragorn.inter.net.il) (192.114.186.23) by sourceware.org with SMTP; 8 Aug 2004 19:28:33 -0000 Received: from zaretski (pns03-207-125.inter.net.il [80.230.207.125]) by aragorn.inter.net.il (MOS 3.4.6-GR) with ESMTP id ECK93337; Sun, 8 Aug 2004 22:28:28 +0300 (IDT) Date: Sun, 08 Aug 2004 19:28:00 -0000 From: "Eli Zaretskii" To: Michael Chastain Message-Id: <6654-Sun08Aug2004222553+0300-eliz@gnu.org> CC: kettenis@chello.nl, gdb-patches@sources.redhat.com, cagney@gnu.org In-reply-to: <4115FF44.nail59F11C8I0@mindspring.com> (message from Michael Chastain on Sun, 08 Aug 2004 06:24:04 -0400) Subject: Re: [PATCH] Improve i386 prologue analyzer Reply-to: Eli Zaretskii References: <200408012158.i71LwpRw033840@elgar.kettenis.dyndns.org> <3405-Mon02Aug2004070159+0300-eliz@gnu.org> <410EAFBB.5080102@gnu.org> <2914-Tue03Aug2004065313+0300-eliz@gnu.org> <200408061933.i76JX3HJ008032@elgar.kettenis.dyndns.org> <4113EA3B.3000900@gnu.org> <2914-Sat07Aug2004183455+0300-eliz@gnu.org> <41150161.3000306@gnu.org> <41155A83.nail9VC11PTRT@mindspring.com> <7704-Sun08Aug2004065437+0300-eliz@gnu.org> <4115FF44.nail59F11C8I0@mindspring.com> X-SW-Source: 2004-08/txt/msg00266.txt.bz2 > Date: Sun, 08 Aug 2004 06:24:04 -0400 > From: Michael Chastain > > eliz> If so, could you please explain why you think it needs any more > eliz> ``marinating'' in HEAD? > > It's a new design. If that's the problem, we could use the less invasive change that I posted. It just adds a few more cases to a switch, but leaves the overall structure of the code intact. > And this feature interacts with many different external variations. > For example, I haven't seen anyone test it with gcc 2. > Or with a program that uses a lot of floating point. As Mark points out, these issues are either already broken or unaffected.