From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: yao@codesourcery.com (Yao Qi)
Cc: gdb-patches@sourceware.org
Subject: Re: Displaced stepping 0002: refactor and create some copy helpers
Date: Mon, 28 Feb 2011 17:53:00 -0000 [thread overview]
Message-ID: <201102281736.p1SHajew004773@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <4D692067.9020307@codesourcery.com> from "Yao Qi" at Feb 26, 2011 11:46:47 PM
Yao Qi wrote:
> The patch continues to refactor code, in order to
> 1) make copy functions separated for ARM and Thumb,
I think it makes sense to split the copy functions into the part that actually
decodes the instruction and installs the target instruction (which depends on
ARM vs. Thumb), and the part that sets up registers and installs the cleanup etc.
(which only depends on the semantics of the instruction, not its encoding).
For symmetry, I'd then prefer if *all* copy functions were split up that way
(in the end, you'll probably need all of them anyway, since just about all
ARM instructions have an alternate encoding as Thumb/Thumb-2).
> 2) define some copy helper functions for some ARM and Thumb-2 instructions.
These look really awkward to me, what with the union and all those function
pointers ... It seems preferable to me to keep instruction decoding
between ARM and Thumb fully separate, even if this means we have a small
amount of duplication.
> -copy_unmodified (struct gdbarch *gdbarch, uint32_t insn,
> - const char *iname, struct displaced_step_closure *dsc)
> +arm_copy_unmodified (uint32_t insn, const char *iname,
> + struct displaced_step_closure *dsc)
Again for symmetry reasons, it's probably better if *all* copy_ functions
get the gdbarch, even if they currently don't need it.
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-28 17:37 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 14:17 [patch 0/3] Displaced stepping for 16-bit Thumb instructions 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
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 [this message]
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 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-23 11:32 ` Yao Qi
2011-05-27 22:11 ` Ulrich Weigand
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: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: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=201102281736.p1SHajew004773@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