From: tixy@yxit.co.uk (Tixy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5] ARM: Add generic instruction opcode manipulation helpers
Date: Tue, 31 Jan 2012 18:22:20 +0000 [thread overview]
Message-ID: <1328034140.2464.3.camel@computer2.home> (raw)
In-Reply-To: <1328008180-28542-1-git-send-email-dave.martin@linaro.org>
On Tue, 2012-01-31 at 11:09 +0000, Dave Martin wrote:
> This patch adds some endianness-agnostic helpers to convert machine
> instructions between canonical integer form and in-memory
> representation.
>
> A canonical integer form for representing instructions is also
> formalised here.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> Acked-by: Nicolas Pitre <nico@linaro.org>
I can confirm this version applies and builds cleanly against
linux-next. And works with Rabin 's jump label support patches.
--
Tixy
> ---
> Changes since v1:
>
> v5: Avoid inclusion of C headers or definition of the __opcode_*
> macros when opcodes.h is included in assembler files. Since
> the __opcode_* macros rely on C declarations, they are not
> directly usable in assembler anyway.
>
> v4: Rebase on top of Leif's patch which created <asm/opcodes.h>
> ARM: 7206/1: Add generic ARM instruction set condition code checks.
>
> No functional changes.
>
> v3: Fix some stupid errors:
>
> * remove bogus extra (x) in __opcode_to_mem_arm
> * fix use of nonexistent "thumb_opcode" argument in
> __opcode_thumb32_{first,second} which causes these
> macros to be broken.
>
> v2: Remove unnecessary typedef for arm_opcode_t.
>
> The general "everything is a word" concept works just fine here --
> we don't need a typedef, and people will probably not use it
> anyway.
>
> arch/arm/include/asm/opcodes.h | 59 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/opcodes.h b/arch/arm/include/asm/opcodes.h
> index c0efdd6..19c48de 100644
> --- a/arch/arm/include/asm/opcodes.h
> +++ b/arch/arm/include/asm/opcodes.h
> @@ -17,4 +17,63 @@ extern asmlinkage unsigned int arm_check_condition(u32 opcode, u32 psr);
> #define ARM_OPCODE_CONDTEST_PASS 1
> #define ARM_OPCODE_CONDTEST_UNCOND 2
>
> +
> +/*
> + * Opcode byteswap helpers
> + *
> + * These macros help with converting instructions between a canonical integer
> + * format and in-memory representation, in an endianness-agnostic manner.
> + *
> + * __mem_to_opcode_*() convert from in-memory representation to canonical form.
> + * __opcode_to_mem_*() convert from canonical form to in-memory representation.
> + *
> + *
> + * Canonical instruction representation:
> + *
> + * ARM: 0xKKLLMMNN
> + * Thumb 16-bit: 0x0000KKLL, where KK < 0xE8
> + * Thumb 32-bit: 0xKKLLMMNN, where KK >= 0xE8
> + *
> + * There is no way to distinguish an ARM instruction in canonical representation
> + * from a Thumb instruction (just as these cannot be distinguished in memory).
> + * Where this distinction is important, it needs to be tracked separately.
> + *
> + * Note that values in the range 0x0000E800..0xE7FFFFFF intentionally do not
> + * represent any valid Thumb-2 instruction. For this range,
> + * __opcode_is_thumb32() and __opcode_is_thumb16() will both be false.
> + */
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/types.h>
> +#include <linux/swab.h>
> +
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +#define __opcode_to_mem_arm(x) swab32(x)
> +#define __opcode_to_mem_thumb16(x) swab16(x)
> +#define __opcode_to_mem_thumb32(x) swahb32(x)
> +#else
> +#define __opcode_to_mem_arm(x) ((u32)(x))
> +#define __opcode_to_mem_thumb16(x) ((u16)(x))
> +#define __opcode_to_mem_thumb32(x) swahw32(x)
> +#endif
> +
> +#define __mem_to_opcode_arm(x) __opcode_to_mem_arm(x)
> +#define __mem_to_opcode_thumb16(x) __opcode_to_mem_thumb16(x)
> +#define __mem_to_opcode_thumb32(x) __opcode_to_mem_thumb32(x)
> +
> +/* Operations specific to Thumb opcodes */
> +
> +/* Instruction size checks: */
> +#define __opcode_is_thumb32(x) ((u32)(x) >= 0xE8000000UL)
> +#define __opcode_is_thumb16(x) ((u32)(x) < 0xE800UL)
> +
> +/* Operations to construct or split 32-bit Thumb instructions: */
> +#define __opcode_thumb32_first(x) ((u16)((x) >> 16))
> +#define __opcode_thumb32_second(x) ((u16)(x))
> +#define __opcode_thumb32_compose(first, second) \
> + (((u32)(u16)(first) << 16) | (u32)(u16)(second))
> +
> +#endif /* __ASSEMBLY__ */
> +
> #endif /* __ASM_ARM_OPCODES_H */
next prev parent reply other threads:[~2012-01-31 18:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 11:09 [PATCH v5] ARM: Add generic instruction opcode manipulation helpers Dave Martin
2012-01-31 18:22 ` Tixy [this message]
2012-01-31 18:27 ` Dave Martin
2012-01-31 18:39 ` Tixy
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=1328034140.2464.3.camel@computer2.home \
--to=tixy@yxit.co.uk \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).