Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Richard.Earnshaw@arm.com, Elena Zannoni <ezannoni@redhat.com>,
	gdb@sources.redhat.com
Subject: Re: read_register_byte can't work with pseudo-reg model
Date: Thu, 16 May 2002 08:36:00 -0000	[thread overview]
Message-ID: <200205161535.QAA09516@cam-mail2.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Thu, 16 May 2002 09:41:20 EDT." <3CE3B700.3060302@cygnus.com>

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

> > I'm guessing. Try:
> >> 
> >> 	if (REGISTER_READ_P ())
> >> 	  {
> >> 	    do something fairly sane;
> >> 	  }
> >> 	else
> >> 	  {
> >> 	    all the legacy cruft including the call to
> >> 	    legacy_read_register_gen() and that test.
> >> 	  }
> >> 
> >> Thing is that there is only one target in the FSF using 
> >> READ_REGISTER_P() so there is this dividing line - something using 
> >> read_register_p() can be given far stronger requirements than for the 
> >> older code.
> > 
> > 
> > Which target is that, and where is READ_REGISTER_P ?  I can't find 
> > anything in the either the source or the mailing lists.  Mind you, the 
> > web-based mailing list search even fails to find your message when I 
> > search for READ_REGISTER_P.

Ok, the following solves my problem; it also makes saving/restoring the 
regcache far more efficient on machines that have that have 
READ_REGISTER_P.

The only assumption is that if this is defined, then pseudos do not need 
unique entries in the regcache (ie they always map onto physical 
registers), so we can copy the regcache simply by iterating over 
0..NUM_REGS.

I need to re-baseline my testsuite runs, but the results look pretty 
encouraging compared to previous runs.

Elena, would this be compatible with the SH model?

R.

	* regcache.c (read_register_bytes): If read_register_p is defined
	and we are saving the entire register set, then short-cut the
	save operation.
	(write_register_bytes): Similarly for write_register_p and restoring
	the register set.



[-- Attachment #2: gdb-regbytes.patch --]
[-- Type: text/x-patch , Size: 1971 bytes --]

Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.34
diff -p -r1.34 regcache.c
*** regcache.c	6 Apr 2002 00:02:50 -0000	1.34
--- regcache.c	16 May 2002 15:31:56 -0000
*************** read_register_bytes (int in_start, char 
*** 228,233 ****
--- 228,248 ----
    int regnum;
    char *reg_buf = alloca (MAX_REGISTER_RAW_SIZE);
  
+   if (gdbarch_register_read_p (current_gdbarch)
+       && in_start == 0 && in_len == REGISTER_BYTES) /* OK Use.  */
+     {
+       /* We assume that if the target has set register_read_p() then
+ 	 all the pseuos will be correctly mapped onto raw registers.
+ 	 Therefore, the regcache describes only the registers in the
+ 	 range [0..NUM_REGS) and the code for reading the entire
+ 	 regset becomes much simpler.  */
+ 
+       for (regnum = 0; regnum < NUM_REGS; regnum++)
+ 	regcache_read (regnum, in_buf + REGISTER_BYTE (regnum));
+ 
+       return;
+     }
+ 
    /* See if we are trying to read bytes from out-of-date registers.  If so,
       update just those registers.  */
  
*************** write_register_bytes (int myregstart, ch
*** 397,402 ****
--- 412,432 ----
    int regnum;
  
    target_prepare_to_store ();
+ 
+   if (gdbarch_register_write_p (current_gdbarch)
+       && myregstart == 0 && inlen == REGISTER_BYTES) /* OK Use.  */
+     {
+       /* We assume that if the target has set register_write_p() then
+ 	 all the pseuos will be correctly mapped onto raw registers.
+ 	 Therefore, the regcache describes only the registers in the
+ 	 range [0..NUM_REGS) and the code for restoring things becomes
+ 	 much simpler.  */
+ 
+       for (regnum = 0; regnum < NUM_REGS; regnum++)
+ 	regcache_write (regnum, myaddr + REGISTER_BYTE (regnum));
+ 
+       return;
+     }
  
    /* Scan through the registers updating any that are covered by the
       range myregstart<=>myregend using write_register_gen, which does

  parent reply	other threads:[~2002-05-16 15:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-15  9:52 Richard Earnshaw
2002-05-15 12:43 ` Andrew Cagney
2002-05-16  5:19   ` Richard Earnshaw
2002-05-16  6:41     ` Andrew Cagney
2002-05-16  6:48       ` Richard Earnshaw
2002-05-16 12:08         ` Andrew Cagney
2002-05-16  8:36       ` Richard Earnshaw [this message]
2002-05-16 15:29         ` Andrew Cagney
2002-05-17  6:14           ` Richard Earnshaw
2002-05-17  7:51             ` Richard Earnshaw

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=200205161535.QAA09516@cam-mail2.cambridge.arm.com \
    --to=rearnsha@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=ac131313@cygnus.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb@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