From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5] ARM: Add generic instruction opcode manipulation helpers
Date: Tue, 31 Jan 2012 18:27:12 +0000 [thread overview]
Message-ID: <20120131182643.GA32536@linaro.org> (raw)
In-Reply-To: <1328034140.2464.3.camel@computer2.home>
On Tue, Jan 31, 2012 at 06:22:20PM +0000, Tixy wrote:
> 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.
OK -- thanks. Can I add your Tested-by for completeness?
Cheers
---Dave
>
> --
> 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:27 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
2012-01-31 18:27 ` Dave Martin [this message]
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=20120131182643.GA32536@linaro.org \
--to=dave.martin@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.