From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFA] SSE registers for cygxin target. Date: Mon, 26 Nov 2001 14:23:00 -0000 Message-id: <20011126222315.GA10876@redhat.com> References: <3C02A966.30003@cygnus.com> X-SW-Source: 2001-11/msg00460.html On Mon, Nov 26, 2001 at 03:43:18PM -0500, Andrew Cagney wrote: >>On Mon, 26 Nov 2001, Pierre Muller wrote: >> >> >>>-#undef HAVE_SSE_REGS /* FIXME! win32-nat.c needs to support XMMi >>>registers */ >>>+/* Use SSE registers if winnt.h contains information about them. */ >>>+#ifdef HAVE_CONTEXT_EXTENDED_REGISTERS >>>+#define HAVE_SSE_REGS >>>+#else >> >> >>Is it wise to have SSE registers supported based on the compile-time >>test? What if the machine on which GDB runs doesn't have SSE? Don't you >>need a run-time test as well? > >In theory? Yes, definitly. In reality? GDB has been avoiding the >problem and instead has been hardwiring the configurations. Sigh. > >(This also looks like the PPC and SPARC problem - regcache_collect() is >flushing it out ....) > >The theory goes something like this: > > o regcache is made large enough to hold > all the registers (SSE in this case) > > o each target (remote.c, *-nat.c) all supply > and/sor collect the registers they have > into the regcache > > o on the other side, core-gdbarch register read/write > are (dynamically) configured to display > the registers, within the register cache > >Things to note: > > o the core and the target can disagree on > which registers are available but _not_ > on the layout of the regcache. > > o GDB is going to need to make a pretty good > educated guess as to what should be displayed > when it starts - there may be no target > to tell the truth. > >This is why I've been hacking remote.c - more changes to follow. So, should I hold off accepting this patch, then? It seems pretty straight-forward except for this issue. cgf From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21384 invoked by alias); 26 Nov 2001 22:23:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21344 invoked from network); 26 Nov 2001 22:23:21 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (207.175.42.154) by hostedprojects.ges.redhat.com with SMTP; 26 Nov 2001 22:23:21 -0000 Received: from trixie.bosbc.com (cgf.cipe.redhat.com [10.0.1.172]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id fAQMNKq25493 for ; Mon, 26 Nov 2001 17:23:20 -0500 Received: (from cgf@localhost) by trixie.bosbc.com (8.11.6/8.8.7) id fAQMNFQ10991 for gdb-patches@sources.redhat.com; Mon, 26 Nov 2001 17:23:15 -0500 Date: Tue, 13 Nov 2001 08:51:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFA] SSE registers for cygxin target. Message-ID: <20011126222315.GA10876@redhat.com> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3C02A966.30003@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C02A966.30003@cygnus.com> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2001-11/txt/msg00245.txt.bz2 Message-ID: <20011113085100.fCdPKjaw53GCnmzEtTSkx5rWv5w5qs5QXh_Do-_nl2Y@z> On Mon, Nov 26, 2001 at 03:43:18PM -0500, Andrew Cagney wrote: >>On Mon, 26 Nov 2001, Pierre Muller wrote: >> >> >>>-#undef HAVE_SSE_REGS /* FIXME! win32-nat.c needs to support XMMi >>>registers */ >>>+/* Use SSE registers if winnt.h contains information about them. */ >>>+#ifdef HAVE_CONTEXT_EXTENDED_REGISTERS >>>+#define HAVE_SSE_REGS >>>+#else >> >> >>Is it wise to have SSE registers supported based on the compile-time >>test? What if the machine on which GDB runs doesn't have SSE? Don't you >>need a run-time test as well? > >In theory? Yes, definitly. In reality? GDB has been avoiding the >problem and instead has been hardwiring the configurations. Sigh. > >(This also looks like the PPC and SPARC problem - regcache_collect() is >flushing it out ....) > >The theory goes something like this: > > o regcache is made large enough to hold > all the registers (SSE in this case) > > o each target (remote.c, *-nat.c) all supply > and/sor collect the registers they have > into the regcache > > o on the other side, core-gdbarch register read/write > are (dynamically) configured to display > the registers, within the register cache > >Things to note: > > o the core and the target can disagree on > which registers are available but _not_ > on the layout of the regcache. > > o GDB is going to need to make a pretty good > educated guess as to what should be displayed > when it starts - there may be no target > to tell the truth. > >This is why I've been hacking remote.c - more changes to follow. So, should I hold off accepting this patch, then? It seems pretty straight-forward except for this issue. cgf