Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: Don't use deprecated regcache functions
Date: Thu, 20 Apr 2006 17:02:00 -0000	[thread overview]
Message-ID: <20060420170239.GI11710@nevyn.them.org> (raw)
In-Reply-To: <20060411.141334.116677120.davem@davemloft.net>

On Tue, Apr 11, 2006 at 02:13:34PM -0700, David S. Miller wrote:
> From: Daniel Jacobowitz <drow@false.org>
> Date: Tue, 11 Apr 2006 09:00:57 -0400
> 
> > On Tue, Apr 11, 2006 at 01:39:09AM -0700, David S. Miller wrote:
> > > Otherwise, ok to apply?
> > 
> > > -      deprecated_read_register_gen (regno, raw);
> > > +      regcache_raw_collect (current_regcache, regno, raw);
> > >        thread_db_fetch_registers (-1);
> > >        regcache_raw_supply (current_regcache, regno, raw);
> > 
> > I might be mistaken, but what the heck does the call to
> > thread_db_fetch_registers accomplish?  I think nothing.
> 
> The solaris thread support does the same thing.  And that code
> uses the more correct regcache_raw_collect() which is partly how
> I noticed this.
> 
> What's happening here is that if we're only writing one register
> we make sure to read in all the other registers first, then we
> write the changing register back into the regcache.

Well, yes.  Sorry for sending you off in the wrong direction; that's
not actually what I meant.  The bit that doesn't follow is:

> In any event, the code we are discussing here in the Linux thread_db
> code really is needed and it's related to the issues I've discussed
> above.

No, it really shouldn't be, for those same reasons.  But...

[long, mostly incorrect analysis deleted here.  This is confusing.]

[There's a lot more prepare-to-store methods than you
thought; while only one target defines the macro, many set it in the
target vector to_prepare_to_store.]

-      deprecated_read_register_gen (regno, raw);
+      regcache_raw_collect (current_regcache, regno, raw);
       thread_db_fetch_registers (-1);
       regcache_raw_supply (current_regcache, regno, raw);

fill_gregset (at least the example I checked, SPARC) will not read
registers as necessary - it also uses regcache_raw_collect.  So some
members of the gregset won't necessarily be filled in as valid unless
all registers are fetched first.  So that suggests the regno == -1 case
is bogus too.  Fortunately the lion's share of calls to these functions
come from regcache.c, which only ever writes one register at a time.

I think:

  - The calls to fill_gregset and fill_fpregset necessitate using
    target_fetch_registers (-1).  That's more or less the same as
    thread_db_fetch_registers (-1).  Either works.

  - What was previously unclear was that thread_db_fetch_registers
    may clobber already fetched registers.  How naughty.

  - It's totally unclear how the -1 case could work, since we can't
    fetch the registers without clobbering what we wanted to write
    out, which may explain why we previously didn't.  We'd need to
    preserve all the cached registers.  Another reason not to use
    the gregset functions this way.

What a mess.

Anyway, I guess the mess is long-standing and currently not a problem,
so go ahead and check in the change to use regcache_raw_collect.

-- 
Daniel Jacobowitz
CodeSourcery


  parent reply	other threads:[~2006-04-20 17:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-11  8:39 David S. Miller
2006-04-11 13:01 ` Daniel Jacobowitz
2006-04-11 21:13   ` David S. Miller
2006-04-12 19:25     ` Michael Snyder
2006-04-13  1:09       ` David S. Miller
2006-04-13  2:41         ` Michael Snyder
2006-04-13  4:05           ` David S. Miller
2006-04-13 18:58             ` Michael Snyder
2006-04-20 17:02     ` Daniel Jacobowitz [this message]
2006-05-05 22:43       ` David S. Miller

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=20060420170239.GI11710@nevyn.them.org \
    --to=drow@false.org \
    --cc=davem@davemloft.net \
    --cc=gdb-patches@sources.redhat.com \
    /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