From: Ulrich Weigand <uweigand@de.ibm.com>
To: will schmidt <will_schmidt@vnet.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH,powerpc,v2] gdb-power10-single-step
Date: Mon, 29 Mar 2021 17:33:39 +0200 [thread overview]
Message-ID: <20210329153339.GB29554@oc3748833570.ibm.com> (raw)
In-Reply-To: <2abf296edd936056d4e8932049fac751f0ae7152.camel@vnet.ibm.com>
On Fri, Mar 26, 2021 at 07:25:15PM -0500, will schmidt wrote:
> gdb/ChangeLog:
> * gdb/rs6000-tdep;c: Add support for single-stepping of prefixed instructions.
>
> gdb/testsuite/ChangeLog:
> * gdb/testsuite/gdb.arch/powerpc-plxv-nonrel.s: Testcase
>
> using non-relative plxv instructions.
> * gdb/testsuite/gdb.arch/powerpc-plxv-nonrel.exp: Testcase
>
> harness.
Again omit the leading "gdb/" or "gdb/testsuite/". Names should always be
relative to the location of the ChangeLog file that contains the entry.
> @@ -897,30 +902,66 @@ ppc_displaced_step_copy_insn (struct gdbarch *gdbarch,
> size_t len = gdbarch_max_insn_length (gdbarch);
> std::unique_ptr<ppc_displaced_step_copy_insn_closure> closure
> (new ppc_displaced_step_copy_insn_closure (len));
> gdb_byte *buf = closure->buf.data ();
> enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> - int insn;
> + ULONGEST insn;
>
> - read_memory (from, buf, len);
> + len = target_read (current_inferior()->top_target(), TARGET_OBJECT_MEMORY, NULL,
> + buf, from, len);
> + if ((ssize_t) len < PPC_INSN_SIZE)
> + memory_error (TARGET_XFER_E_IO, from);
>
> insn = extract_signed_integer (buf, PPC_INSN_SIZE, byte_order);
> + displaced_debug_printf ("attempting displacement of instruction as: %16lx, length %ld, ",
> + insn, len);
Again, there's too many debug statements, they will flood the log and make
it not really usable. We don't need to print every single instruction here.
> + /* If the instruction is prefixed, handle the instruction size properly. */
> + if ((insn & OP_MASK) == 1 << 26)
> + {
> + /* Handle PNOP. */
> + /* Handle Prefixed instructions with R=0. */
> + if (((insn & PNOP_MASK) == PNOP_INSN) ||
> + ((insn & R_MASK) == R_ZERO))
> + {
> + insn = extract_signed_integer (buf, 2 * PPC_INSN_SIZE, byte_order);
> + displaced_debug_printf ("reloaded instruction: %16lx, length %ld",
> + insn, len);
Likewise we don't need to display each instruction here. This whole block
is probably unnecessary.
> + }
> + else
> + {
> + /* Prefixed with R=1 */
> + /* The prefixed instructions with R=1 will read/write data to/from
> + locations relative to the current PC. We would not be able to
> + fixup after an instruction has written to a displaced location, so
> + decline to displace those instructions. */
> + displaced_debug_printf ("Not displacing prefixed instruction %16lx at %s",
> + insn, paddress (gdbarch, from));
This statement is actually useful and should be kept.
> + return NULL;
> + }
> + } /* prefixed. */
> + else
> + /* non-prefixed. */
> + {
> + /* Set the instruction length to 4 to match the actual instruction
> + length. */
> + len = 4;
> + }
The formatting is odd throughout -- is this just an issue with the email?
Please verify it complies with the GNU coding style.
> /* Assume all atomic sequences start with a Load and Reserve instruction. */
> if (IS_LOAD_AND_RESERVE_INSN (insn))
> {
> displaced_debug_printf ("can't displaced step atomic sequence at %s",
> paddress (gdbarch, from));
> -
> return NULL;
> }
>
> write_memory (to, buf, len);
>
> displaced_debug_printf ("copy %s->%s: %s",
> - paddress (gdbarch, from), paddress (gdbarch, to),
> - displaced_step_dump_bytes (buf, len).c_str ());;
> + paddress (gdbarch, from), paddress (gdbarch, to),
> + displaced_step_dump_bytes (buf, len).c_str ());
Please omit those whitespace changes.
> /* Check for breakpoints in the inferior. If we've found one, place the PC
> right at the breakpoint instruction. */
> else if ((insn & BP_MASK) == BP_INSN)
> - regcache_cooked_write_unsigned (regs, gdbarch_pc_regnum (gdbarch), from);
> + {
> + regcache_cooked_write_unsigned (regs, gdbarch_pc_regnum (gdbarch), from);
> + }
> else
> + {
> /* Handle any other instructions that do not fit in the categories above. */
> + /* set offset to 8 if this is an 8-byte (prefixed) instruction. */
> + if ((insn & OP_MASK) == 1 << 26)
> + offset = 2 * PPC_INSN_SIZE;
> + else
> + offset = PPC_INSN_SIZE;
> regcache_cooked_write_unsigned (regs, gdbarch_pc_regnum (gdbarch),
> from + offset);
> + }
Check the formatting again. Also, I think it would be better to move
calculating the correct offset to the top of the function, just after
insn is read initially.
> for (insn_count = 0; insn_count < atomic_sequence_length; ++insn_count)
> {
> - loc += PPC_INSN_SIZE;
> - insn = read_memory_integer (loc, PPC_INSN_SIZE, byte_order);
> + int cur_insn = read_memory_integer (loc, PPC_INSN_SIZE, byte_order);
> + if ((cur_insn & OP_MASK) == 1 << 26) {
> + loc += 2*PPC_INSN_SIZE;
> + insn = read_memory_integer (loc, 2 * PPC_INSN_SIZE, byte_order);
This seems wrong to me: subsequent code expects "insn" to be a 4-byte value
(e.g. for the if ((insn & OP_MASK) == BC_INSN) check).
Why do you have the read the full 8 byte instruction in the first place?
Nothing depends on the second half.
> + } else {
> + loc += PPC_INSN_SIZE;
> + insn = read_memory_integer (loc, PPC_INSN_SIZE, byte_order);
> + }
Position of the '{' is definitely wrong. Also check the indentation.
> + fprintf_unfiltered(gdb_stdlog,"Warning: read_memory_integer: instruction found here. %08x \n",insn);
This seems left-over from debugging?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2021-03-29 15:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-27 0:25 will schmidt
2021-03-29 15:33 ` Ulrich Weigand [this message]
2021-03-29 22:43 ` [PATCH,rs6000,v3] gdb-power10-single-step will schmidt
2021-03-30 19:47 ` Ulrich Weigand
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=20210329153339.GB29554@oc3748833570.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=will_schmidt@vnet.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).