Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Mark Kettenis <kettenis@chello.nl>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Provide dummy SSE registers in i387_supply_fsave
Date: Thu, 05 Aug 2004 15:43:00 -0000	[thread overview]
Message-ID: <vt2hdrh8uff.fsf@zenia.home> (raw)
In-Reply-To: <41123CCB.5040908@gnu.org>

Andrew Cagney <cagney@gnu.org> writes:

> > Jim's patch to assert that target_fetch_registers did its job broke
> > OpenBSD/i386 and probably most other i386 native debuggers.  The
> > attached patch fixes this.
> > I am wondering however.how this affects other platforms and remote
> > targets.
> 
> Hmm,
> 
> Jim, which systems did the assert patch get tested on?

IA-32 and PowerPC Linux.  i386-linux-nat.c:supply_fpregset calls
dummy_sse_values, which provides the contents of the %xmm registers,
which is what Mark ran into.

This is the concern I was getting at in the first paragraph of the
patch post: the assert is clearly a "fair" check on
target_fetch_registers ("I asked you for this register, and you said
'okay'; were you telling the truth?") and it's clearly a condition
developers would want to know about (using the contents of a register
marked as not valid).  But at the same time, it's easy to believe that
there are lots of register sets in various architectures that have
grown beyond the ability of some targets to fetch.

If it's the case that many arch/target combinations will trigger the
assert, then an assert is too aggressive, and it should probably be a
warning instead.  But silently supplying dummy bits is pretty
unsatisfactory.  As a developer, I wanted to know that regcache.c was
happily fetching invalid contents.  And as a user, I'd like something
more than a suspicious bit pattern to tell me that a given register is
unavailable.


      reply	other threads:[~2004-08-05 15:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05  2:02 Mark Kettenis
2004-08-05 13:57 ` Andrew Cagney
2004-08-05 15:43   ` Jim Blandy [this message]

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=vt2hdrh8uff.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /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