Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: kevinb@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] mips-tdep.c: pseudo-register -> raw register sign extension
Date: Thu, 09 Dec 2010 11:19:00 -0000	[thread overview]
Message-ID: <201012091119.oB9BJ0G1007042@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20101207164737.0bafe0d6@mesquite.lan> (message from Kevin	Buettner on Tue, 7 Dec 2010 16:47:37 -0700)

> Date: Tue, 7 Dec 2010 16:47:37 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> Below is another patch that fixes another problem arising from the
> simulator catching UNPREDICTABLE behavior.  Again, this affects mips64
> targets that are being run in 32-bit mode.
>
> ...
>
> What is happening here is that `l' resides in register s0 and
> the following instruction is the first of line 86:
> 
>     0x800205bc <wack_int+40>:    move    a0,s0
> 
> Note from the log above that `l' (register s0) starts out as -1, but
> is changed by the testing machinery to 4.  In the course of changing
> this value, mips_pseudo_register_write() is called in order to
> transfer the 32-bit pseudo register for s0 to the corresponding 64-bit
> raw register.  Without the patch below, only 32 bits are being
> transferred, thus leaving in place the (high 32-bit) sign extension of
> -1.  When the sim attempts to execute the instruction noted above, it
> first checks to make sure that the sign extension for the register
> being transferred is sane.  It is not, and therefore quits printing
> the UNPREDICTABLE message.  This ends up causing the first failure as
> well as the resulting cascade since GDB prints the following message
> for many of the later commands that it tries to execute:  "Cannot
> execute this command while the selected thread is running. 
> 
> Comments?

Sortof destroys the symmetry between pesudo_register_read and
pseudo_register_write.

> 	* mips-tdep.c (mips_pseudo_register_write): Sign extend 32-bit
> 	cooked values that are being transferred to 64-bit raw registers.
> 
> Index: mips-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mips-tdep.c,v
> retrieving revision 1.508
> diff -u -p -r1.508 mips-tdep.c
> --- mips-tdep.c	28 Nov 2010 04:31:24 -0000	1.508
> +++ mips-tdep.c	7 Dec 2010 21:58:58 -0000
> @@ -582,11 +582,19 @@ mips_pseudo_register_write (struct gdbar
>    else if (register_size (gdbarch, rawnum) >
>  	   register_size (gdbarch, cookednum))
>      {
> -      if (gdbarch_tdep (gdbarch)->mips64_transfers_32bit_regs_p
> -	  || gdbarch_byte_order (gdbarch) == BFD_ENDIAN_LITTLE)
> +      if (gdbarch_tdep (gdbarch)->mips64_transfers_32bit_regs_p)
>  	regcache_raw_write_part (regcache, rawnum, 0, 4, buf);
>        else
> -	regcache_raw_write_part (regcache, rawnum, 4, 4, buf);
> +	{
> +	  /* Sign extend the shortened version of the register prior
> +	     to placing it in the raw register.  This is required for
> +	     some mips64 parts in order to avoid unpredictable behavior.  */
> +	  gdb_byte buf8[8];
> +	  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> +	  LONGEST regval = extract_signed_integer (buf, 4, byte_order);
> +	  store_signed_integer (buf8, 8, byte_order, regval);
> +	  regcache_raw_write (regcache, rawnum, buf8);

How about using regcache_raw_write_signed() here?  I think that
simplifies the code enough to change mips_pseudo_register_read() to
use regcache_raw_read_signed() and get rid of the explicit endian-ness
check as well.


  reply	other threads:[~2010-12-09 11:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-07 23:47 Kevin Buettner
2010-12-09 11:19 ` Mark Kettenis [this message]
2010-12-09 23:20   ` Kevin Buettner
2010-12-15 20:54     ` Kevin Buettner

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=201012091119.oB9BJ0G1007042@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@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