From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14213 invoked by alias); 8 Dec 2009 05:51:16 -0000 Received: (qmail 14203 invoked by uid 22791); 8 Dec 2009 05:51:15 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f183.google.com (HELO mail-px0-f183.google.com) (209.85.216.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Dec 2009 05:51:09 +0000 Received: by pxi13 with SMTP id 13so2582016pxi.24 for ; Mon, 07 Dec 2009 21:51:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.74.8 with SMTP id w8mr863778wfa.192.1260251468221; Mon, 07 Dec 2009 21:51:08 -0800 (PST) In-Reply-To: <4B1D43E1.5010400@vmware.com> References: <4B1D3829.2020509@vmware.com> <20091207174317.GF2891@adacore.com> <4B1D4152.7000200@vmware.com> <20091207180036.GG2891@adacore.com> <4B1D43E1.5010400@vmware.com> From: Hui Zhu Date: Tue, 08 Dec 2009 05:51:00 -0000 Message-ID: Subject: Re: [RFA] Prec x86 MMX 3DNow! SSE SSE2 SSE3 SSSE3 SSE4 support To: Michael Snyder Cc: Joel Brobecker , gdb-patches ml , Mark Kettenis Content-Type: text/plain; charset=ISO-8859-1 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: 2009-12/txt/msg00115.txt.bz2 I think your mean is case 5...10:, right? I did it before, a lot of people told me that they didn't like it. So... And about: + /* 3DNow! prefetch */ + case 0x0f0d: This is really a big change. And In i386-tdep.c, there are a lot of code is like it too. So I suggest we make a special patch to fix all of this code after a clear and deeply discussion. :) What do you think about it? Thanks, Hui On Tue, Dec 8, 2009 at 02:05, Michael Snyder wrote: > Joel Brobecker wrote: >>>> >>>> Let's avoid that extension, as GDB is supposed to be buildable with >>>> a non-GCC compiler. >>> >>> I thought we had given up that requirement? >> >> You might be right, but I don't remember us making that decision. >> Anyone remembers? > > Nah, I'm probably confusing it for when we gave up the > requirement to be compilable by K&R (non-ansii) compilers. > > > >