From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>,
gdb-patches@sources.redhat.com,
Christopher Faylor <cgf@redhat.com>
Subject: Re: [RFA] SSE registers for cygxin target.
Date: Tue, 13 Nov 2001 07:48:00 -0000 [thread overview]
Message-ID: <3C02A966.30003@cygnus.com> (raw)
In-Reply-To: <Pine.SUN.3.91.1011126143653.12758G-100000@is>
> 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.
Andrew
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>,
gdb-patches@sources.redhat.com,
Christopher Faylor <cgf@redhat.com>
Subject: Re: [RFA] SSE registers for cygxin target.
Date: Mon, 26 Nov 2001 12:43:00 -0000 [thread overview]
Message-ID: <3C02A966.30003@cygnus.com> (raw)
Message-ID: <20011126124300.1ueMZ5aVPCt2sOIQCflKZ5BFBc5_gfuXSfLEUANuaoc@z> (raw)
In-Reply-To: <Pine.SUN.3.91.1011126143653.12758G-100000@is>
> 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.
Andrew
next prev parent reply other threads:[~2001-11-26 20:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-26 2:06 Pierre Muller
2001-11-11 11:03 ` Pierre Muller
2001-11-12 8:54 ` Eli Zaretskii
2001-11-13 7:48 ` Andrew Cagney [this message]
2001-11-26 12:43 ` Andrew Cagney
2001-11-26 14:23 ` Christopher Faylor
2001-11-13 8:51 ` Christopher Faylor
2001-11-13 19:54 ` Andrew Cagney
2001-11-13 22:27 ` Christopher Faylor
2001-11-26 21:17 ` Christopher Faylor
2001-11-26 20:47 ` Andrew Cagney
2001-11-26 4:58 ` Pierre Muller
2001-11-12 9:40 ` Pierre Muller
2001-11-26 2:10 ` Pierre Muller
2001-11-11 11:08 ` Pierre Muller
2001-11-11 12:11 ` Corinna Vinschen
2001-11-26 3:44 ` Pierre Muller
2001-11-11 13:37 ` Pierre Muller
2001-11-12 11:29 ` Christopher Faylor
2001-11-12 14:28 ` muller
2001-11-26 10:43 ` muller
2001-11-26 9:40 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C02A966.30003@cygnus.com \
--to=ac131313@cygnus.com \
--cc=cgf@redhat.com \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sources.redhat.com \
--cc=muller@cerbere.u-strasbg.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox