Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: cole945@gmail.com (Wei-cheng Wang)
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/3 v2] Process record support for PowerPC
Date: Mon, 08 Dec 2014 19:12:00 -0000	[thread overview]
Message-ID: <201412081911.sB8JBwnn026708@d03av02.boulder.ibm.com> (raw)
In-Reply-To: <54834422.3060907@gmail.com> from "Wei-cheng Wang" at Dec 07, 2014 02:00:02 AM

Wei-cheng Wang wrote:


This is looking very good now; just a couple of minor issues left.


> 	* configure.tgt (powerpc*-*-linux): A linux-record.o to
Typo "Add"
> 	gdb_target_obs.
> 	(ppc_linux_record_tdep, ppc64_linux_record_tdep) New for linux syscal
> 	record.
Missing ":" after ")".  Typo "syscall"
> 	(ppc_canonicalize_syscall, ppc_linux_syscall_record,
> 	ppc_linux_record_signal, ppc_init_linux_record_tdep): New functions.
> 	(ppc_linux_init_abi): Set process_record, process_record_signal.
> 	* ppc-tdep.h: Add ppc_syscall_record and ppc_linux_record_tdep to
> 	gdbarch_tdep.
Should be:  "* ppc-tdep.h (struct gdbarch_tdep): Add ..."

> 	(ppc_process_record): New declaration.
> 	* rs6000-tdep.c: (ppc_record_vsr, ppc_process_record_op4,
No ":" since we start with a "(".
> 	ppc_process_record_op19, ppc_process_record_op31,
> 	ppc_process_record_op59, ppc_process_record_op60,
> 	ppc_process_record_op63, ppc_process_record): New functions.
> 
> Changelog for testsuite
> 
> 2014-12-06  Wei-cheng Wang  <cole945@gmail.com>
> 
> 	* lib/gdb.exp: supports_process_record): Return true for
> 	powerpc*-*-linux* (supports_reverse): Likewise.

	* lib/gdb.exp: supports_process_record): Return true for
	powerpc*-*-linux*.
	(supports_reverse): Likewise.



> diff --git a/gdb/ppc-tdep.h b/gdb/ppc-tdep.h
> index 08554ff..81e11a4 100644
> --- a/gdb/ppc-tdep.h
> +++ b/gdb/ppc-tdep.h
> @@ -25,6 +25,7 @@ struct frame_info;
>   struct value;
>   struct regcache;
>   struct type;
> +struct linux_record_tdep;
> 
>   /* From ppc-sysv-tdep.c ...  */
>   enum return_value_convention ppc_sysv_abi_return_value (struct gdbarch *gdbarch,
> @@ -259,6 +260,9 @@ struct gdbarch_tdep
>       /* ISA-specific types.  */
>       struct type *ppc_builtin_type_vec64;
>       struct type *ppc_builtin_type_vec128;
> +
> +    int (*ppc_syscall_record) (struct regcache *regcache);
> +    struct linux_record_tdep *ppc_linux_record_tdep;
>   };

The generic tdep file should not use any linux-specific data types.
It would be better remove the ppc_linux_record_tdep field and handle
this fully in ppc-linux-tdep.c, either by using two ppc_syscall_record
routines or (better) by having the routine do a tdep->wordsize check.


> +/* PPC process record-replay */
> +
> +struct linux_record_tdep ppc_linux_record_tdep;
> +struct linux_record_tdep ppc64_linux_record_tdep;

Should be "static".

> +ppc_linux_record_signal (struct gdbarch *gdbarch, struct regcache *regcache,
> +			 enum gdb_signal signal)
[snip]
> +  for (i = 3; i <= 6; i++)
> +    {
> +      if (record_full_arch_list_add_reg (regcache, tdep->ppc_gp0_regnum + i))
> +	return -1;
> +    }
> +  if (tdep->wordsize == 8
> +      && record_full_arch_list_add_reg (regcache, tdep->ppc_gp0_regnum + 12))
> +    return -1;
Probably better to just clobber all registers 3 .. 12, just in case at some
point the kernel changes to pass more arguments to signal handlers.  (No
need really to check for tdep->wordsize, cannot hurt to record r12 also
on 32-bit.)

> +ppc_init_linux_record_tdep (struct gdbarch *gdbarch,
> +			    struct linux_record_tdep *record_tdep)
[snip]
> +      record_tdep->size_pointer = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
> +      record_tdep->size_int = gdbarch_int_bit (gdbarch) / TARGET_CHAR_BIT;
> +      record_tdep->size_long = gdbarch_long_bit (gdbarch) / TARGET_CHAR_BIT;
> +      record_tdep->size_ulong = gdbarch_long_bit (gdbarch) / TARGET_CHAR_BIT;
Might as well use hard-coded values here, we use hard-coded values for
everything else ...


> +ppc_process_record_op4 (struct gdbarch *gdbarch, struct regcache *regcache,
> +                          CORE_ADDR addr, uint32_t insn)
[snip]
> +    case 32:		/* Vector Multiply-High-Add Signed Halfword Saturate */
> +    case 33:		/* Vector Multiply-High-Round-Add Signed Halfword Saturate */
> +    case 39:		/* Vector Multiply-Sum Unsigned Halfword Saturate */
> +    case 41:		/* Vector Multiply-Sum Signed Halfword Saturate */
> +    case 42:		/* Vector Select */
> +    case 43:		/* Vector Permute */
> +    case 44:		/* Vector Shift Left Double by Octet Immediate */
> +    case 60:		/* Vector Add Extended Unsigned Quadword Modulo */
> +    case 61:		/* Vector Add Extended & write Carry Unsigned Quadword */
> +    case 62:		/* Vector Subtract Extended Unsigned Quadword Modulo */
> +    case 63:		/* Vector Subtract Extended & write Carry Unsigned Quadword */
> +    case 34:		/* Vector Multiply-Low-Add Unsigned Halfword Modulo */
> +    case 36:		/* Vector Multiply-Sum Unsigned Byte Modulo */
> +    case 37:		/* Vector Multiply-Sum Mixed Byte Modulo */
> +    case 38:		/* Vector Multiply-Sum Unsigned Halfword Modulo */
> +    case 40:		/* Vector Multiply-Sum Signed Halfword Modulo */
> +    case 46:		/* Vector Multiply-Add Single-Precision */
> +    case 47:		/* Vector Negative Multiply-Subtract Single-Precision */
These still do not handle the case of VRC != 0 correctly; see my reply
to the 0/3 email.


> +ppc_process_record_op60 (struct gdbarch *gdbarch, struct regcache *regcache,
> +			   CORE_ADDR addr, uint32_t insn)
[snip]
> +    case 61:		/* VSX Scalar Test for software Divide Double-Precision */
Should move down to 125/93

> +    case 240:		/* VSX Vector Copy Sign Double-Precision */
> +    case 208:		/* VSX Vector Copy Sign Single-Precision */
These two do not modify fpscr, should move down.


> +ppc_process_record_op63 (struct gdbarch *gdbarch, struct regcache *regcache,
> +			   CORE_ADDR addr, uint32_t insn)
[snip]
> +    case 130:		/* DFP Compare Ordered Quad */
> +    case 162:		/* DFP Test Exponent Quad */
> +    case 194:		/* DFP Test Data Class Quad */
> +    case 226:		/* DFP Test Data Group Quad */
> +    case 642:		/* DFP Compare Unordered Quad */
> +    case 674:		/* DFP Test Significance Quad */
None of these actually have an RC bit, but they unconditionally set CR.
(Sorry, didn't notice that on the initial review.)
> +      if (PPC_RC (insn))
> +	record_full_arch_list_add_reg (regcache, tdep->ppc_cr_regnum);
> +      record_full_arch_list_add_reg (regcache, tdep->ppc_fpscr_regnum);
> +      return 0;

> +    case 23:		/* Floating Select */
> +    case 583:		/* Move From FPSCR */
> +      record_full_arch_list_add_reg (regcache, tdep->ppc_cr_regnum);
But these two do have an RC bit.  (Likewise.)


> +ppc_process_record (struct gdbarch *gdbarch, struct regcache *regcache,
> +                     CORE_ADDR addr)
[snip]
> +    case 56:		/* Load Quadword */
> +      if (PPC_FIELD (insn, 30, 2) != 0)
> +	goto UNKNOWN_OP;
As discussed in the other email, this test is actually wrong here;
sorry.  The test should only be with opcode 57.


Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2014-12-08 19:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-06 18:00 Wei-cheng Wang
2014-12-08 19:12 ` Ulrich Weigand [this message]
2014-12-17 17:07   ` [PATCH 2/3 v3] " Wei-cheng Wang
2014-12-17 18:41     ` Ulrich Weigand
2014-12-25 17:27       ` [PATCH 2/3 v4] " Wei-cheng Wang
2015-01-01 14:19         ` Ulrich Weigand
2015-01-04 16:27           ` Wei-cheng Wang
2015-01-06 12:42             ` Ulrich Weigand
2015-01-17  6:02               ` Wei-cheng Wang
2015-01-17 11:47                 ` Ulrich Weigand
2015-01-17 18:53                   ` Joel Brobecker
2015-01-17 21:20                     ` Broken build: rs6000-tdep.c: 32-bit host --enable-targets=all --enable-64-bit-bfd [Re: [PATCH 2/3 v4] Process record support for PowerPC] Jan Kratochvil
2015-01-18  4:47                       ` Wei-cheng Wang
2015-01-18  7:01                         ` Jan Kratochvil
2015-01-18  8:01                           ` Wei-cheng Wang
2015-01-19  7:48                             ` Joel Brobecker
2015-01-19 16:10                               ` [PATCH 2/3 v4] Process record support for PowerPC Wei-cheng Wang
2015-01-19 18:05                                 ` Ulrich Weigand
2015-01-20 16:03                                   ` Wei-cheng Wang
2015-01-20 18:14                                     ` Ulrich Weigand
2015-01-26 17:19                                       ` Ulrich Weigand
2015-01-26 17:19                                         ` Wei-cheng Wang
2015-01-26 19:16                                           ` Doug Evans
2015-01-26 20:29                                             ` Doug Evans

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=201412081911.sB8JBwnn026708@d03av02.boulder.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=cole945@gmail.com \
    --cc=gdb-patches@sourceware.org \
    /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