From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: yao@codesourcery.com (Yao Qi)
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 2/3] Displaced stepping for 16-bit Thumb instructions
Date: Thu, 17 Feb 2011 19:46:00 -0000 [thread overview]
Message-ID: <201102171922.p1HJMM9I029170@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <4D15FCD1.7070706@codesourcery.com> from "Yao Qi" at Dec 25, 2010 10:16:49 PM
Yao Qi wrote:
> Current implementation of displaced stepping in ARM assumes instruction
> size is fixed 32-bit. Patch 2 is to rewrite some infrastructure code to
> be ready to handle non-32-bit instructions. This patch doesn't change
> any GDB functionality either.
Thanks for working on this!
> * gdb/arm-tdep.h (struct displaced_step_closure): Add new field
> modinsns.
> Remove field modinsn.
> (RECORD_MOD_32BIT_INSN): New macro.
> (RECORD_MOD_16BIT_INSN): New macro.
> (RECORD_MOD_INSN): New macro.
> - unsigned long modinsn[DISPLACED_MODIFIED_INSNS];
> +
> + struct insn
> + {
> + union
> + {
> + unsigned long a;
> + unsigned short t;
> + }insn;
> + unsigned short size;
> + }modinsns[DISPLACED_MODIFIED_INSNS];
> +
I don't think this is the right way to go. You cannot have a mixture of
ARM and Thumb instructions in a single modinsn block, and if you have
Thumb instructions, they all need to be transfered in 16-bit chunks,
even the 32-bit Thumb2 instructions, to get the endian conversion right.
So I think you should rather keep a single modinsn array of unsigned long.
When filling it in, ARM instructions are handled as today, 16-bit Thumb
instructions are likewise just filled into one modinsn slot, and 32-bit
Thumb instructions are filled into two modinsn slots.
When copying the modinsn array out to the target, each slot is transfered
as 4 bytes in ARM mode, and as 2 bytes in Thumb mode. To know in which
mode you are, it is probably best to have a single flag in the struct
displaced_step_closure that indicated whether it is ARM or Thumb; this
flag would be set once at the start of arm_process_displaced_insn, and
used throughout the code whereever we need to know the mode.
This approach would make most of the changes in this patch obsolete.
> (cleanup_branch): Replace magic number by macros.
> - ULONGEST pc = displaced_read_reg (regs, from, 15);
> - displaced_write_reg (regs, dsc, 14, pc - 4, CANNOT_WRITE_PC);
> + ULONGEST pc = displaced_read_reg (regs, from, ARM_PC_REGNUM);
> + displaced_write_reg (regs, dsc, ARM_LR_REGNUM, pc - 4, CANNOT_WRITE_PC);
I'm not sure about this change -- other callers just pass in plain
register numbers as well ... Either those should all be changed,
or none of them. In any case, this is really an unrelated change,
and should be done -if at all- in a separate patch.
> @@ -5908,23 +5928,44 @@ arm_displaced_init_closure (struct gdbarch *gdbarch, CORE_ADDR from,
> CORE_ADDR to, struct displaced_step_closure *dsc)
> {
> struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> - unsigned int i;
> + unsigned int i, len, offset;
> enum bfd_endian byte_order_for_code = gdbarch_byte_order_for_code (gdbarch);
>
> + offset = 0;
> /* Poke modified instruction(s). */
> for (i = 0; i < dsc->numinsns; i++)
> {
> + unsigned long insn;
> + if (dsc->modinsns[i].size == 4)
> + insn = dsc->modinsns[i].insn.a;
> + else if (dsc->modinsns[i].size == 2)
> + insn = dsc->modinsns[i].insn.t;
> + else
> + gdb_assert (0);
> +
> if (debug_displaced)
> - fprintf_unfiltered (gdb_stdlog, "displaced: writing insn %.8lx at "
> - "%.8lx\n", (unsigned long) dsc->modinsn[i],
> - (unsigned long) to + i * 4);
> - write_memory_unsigned_integer (to + i * 4, 4, byte_order_for_code,
> - dsc->modinsn[i]);
> + {
> + fprintf_unfiltered (gdb_stdlog, "displaced: writing insn ");
> + if (dsc->modinsns[i].size == 4)
> + fprintf_unfiltered (gdb_stdlog, "%.8lx",
> + dsc->modinsns[i].insn.a);
> + else if (dsc->modinsns[i].size == 2)
> + fprintf_unfiltered (gdb_stdlog, "%.4x",
> + dsc->modinsns[i].insn.t);
> +
> + fprintf_unfiltered (gdb_stdlog, " at %.8lx\n",
> + (unsigned long) to + offset);
> + }
> + write_memory_unsigned_integer (to + offset, dsc->modinsns[i].size,
> + byte_order_for_code,
> + insn);
> + offset += dsc->modinsns[i].size;
> }
As indicated above, this should just copy dsc->numinsns chunks of size 4
in ARM mode, and of size 2 in Thumb mode.
> /* Put breakpoint afterwards. */
> - write_memory (to + dsc->numinsns * 4, tdep->arm_breakpoint,
> - tdep->arm_breakpoint_size);
> + write_memory (to + arm_displaced_step_breakpoint_offset (dsc),
> + arm_breakpoint_from_pc (gdbarch, &from, &len),
> + len);
Calling arm_breakpoint_from_pc is not a good idea, since this calls
arm_pc_is_thumb, which may end up getting a wrong result. Since we
already know whether we're in ARM or Thumb mode, you should just
emit either tdep->arm_breakpoint or tdep->thumb_breakpoint. (Since
we're not *replacing* any instruction here, there is never a need
to use the Thumb-2 breakpoint.)
> @@ -5960,7 +6001,11 @@ arm_displaced_step_fixup (struct gdbarch *gdbarch,
> dsc->cleanup (gdbarch, regs, dsc);
>
> if (!dsc->wrote_to_pc)
> - regcache_cooked_write_unsigned (regs, ARM_PC_REGNUM, dsc->insn_addr + 4);
> + {
> + struct frame_info *fi = get_current_frame ();
> + regcache_cooked_write_unsigned (regs, ARM_PC_REGNUM,
> + arm_get_next_pc_raw(fi, dsc->insn_addr, 0));
> + }
Hmm, arm_get_next_pc_raw tries to follow branches etc, which is probably
not what we want here. Again, I'd rather just check ARM vs. Thumb state
(in Thumb mode we could then check the instruction to see whether it is
a 16-bit or 32-bit instruction --- or even better, the original decoding
step could have just set a flag in dsc).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2011-02-17 19:22 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 14:17 [patch 0/3] " Yao Qi
2010-12-25 14:22 ` [patch 1/3] " Yao Qi
2011-02-17 19:09 ` Ulrich Weigand
2010-12-25 17:09 ` [patch 2/3] " Yao Qi
2011-02-17 19:46 ` Ulrich Weigand [this message]
2011-02-18 6:33 ` Yao Qi
2011-02-18 12:18 ` Ulrich Weigand
2011-02-21 7:41 ` Yao Qi
2011-02-21 20:14 ` Ulrich Weigand
2011-02-25 18:09 ` Yao Qi
2011-02-25 20:17 ` Ulrich Weigand
2011-02-26 14:07 ` Yao Qi
2011-02-28 17:37 ` Ulrich Weigand
2011-03-01 9:01 ` Yao Qi
2011-03-01 16:11 ` Ulrich Weigand
2010-12-25 17:54 ` [patch 3/3] " Yao Qi
2010-12-27 15:15 ` Yao Qi
2011-02-17 20:55 ` Ulrich Weigand
2011-02-18 7:30 ` Yao Qi
2011-02-18 13:25 ` Ulrich Weigand
2011-02-28 2:04 ` Displaced stepping 0003: " Yao Qi
2010-12-29 5:48 ` [patch 0/3] Displaced stepping " Yao Qi
2011-01-13 12:38 ` Yao Qi
2011-02-10 6:48 ` Ping 2 " Yao Qi
2011-02-26 17:50 ` Displaced stepping 0002: refactor and create some copy helpers Yao Qi
2011-02-28 17:53 ` Ulrich Weigand
2011-02-28 2:15 ` Displaced stepping 0004: wip: 32-bit Thumb instructions Yao Qi
2011-03-24 13:49 ` [try 2nd 0/8] Displaced stepping for " Yao Qi
2011-03-24 13:56 ` [try 2nd 1/8] Fix cleanup_branch to take Thumb into account Yao Qi
2011-04-06 20:46 ` Ulrich Weigand
2011-04-07 3:45 ` Yao Qi
2011-03-24 13:58 ` [try 2nd 2/8] Rename copy_* functions to arm_copy_* Yao Qi
2011-04-06 20:51 ` Ulrich Weigand
2011-04-07 8:02 ` Yao Qi
2011-04-19 9:07 ` Yao Qi
2011-04-26 17:09 ` Ulrich Weigand
2011-04-27 10:27 ` Yao Qi
2011-04-27 13:32 ` Ulrich Weigand
2011-04-28 5:05 ` Yao Qi
2011-03-24 14:01 ` [try 2nd 3/8] Refactor copy_svc_os Yao Qi
2011-04-06 20:55 ` Ulrich Weigand
2011-04-07 4:19 ` Yao Qi
2011-03-24 14:05 ` [try 2nd 4/8] Displaced stepping for Thumb 16-bit insn Yao Qi
2011-05-05 13:24 ` Yao Qi
2011-05-10 13:58 ` Ulrich Weigand
2011-05-11 13:06 ` Yao Qi
2011-05-16 17:19 ` Ulrich Weigand
2011-05-17 14:29 ` Yao Qi
2011-05-17 17:20 ` Ulrich Weigand
2011-03-24 14:05 ` [try 2nd 5/8] Displaced stepping for Thumb 32-bit insns Yao Qi
2011-05-05 13:25 ` Yao Qi
2011-05-17 17:14 ` Ulrich Weigand
2011-05-23 11:32 ` Yao Qi
2011-05-27 22:11 ` Ulrich Weigand
2011-05-23 11:32 ` Yao Qi
2011-07-06 10:55 ` Yao Qi
2011-07-15 19:57 ` Ulrich Weigand
2011-07-18 9:26 ` Yao Qi
2011-03-24 14:06 ` [try 2nd 6/8] Rename some functions to arm_* Yao Qi
2011-04-06 20:52 ` Ulrich Weigand
2011-04-07 4:26 ` Yao Qi
2011-03-24 14:11 ` [try 2nd 7/8] Test case Yao Qi
2011-05-05 13:26 ` Yao Qi
2011-05-11 13:15 ` [try 2nd 7/8] Test case: V3 Yao Qi
2011-05-17 17:24 ` Ulrich Weigand
2011-03-24 15:14 ` [try 2nd 8/8] NEWS Yao Qi
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=201102171922.p1HJMM9I029170@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.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