From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] scripts/decodecode: Fix decoding for AArch64 (arm64) instructions
Date: Thu, 28 Sep 2017 19:01:35 +0100 [thread overview]
Message-ID: <20170928180135.GH9892@arm.com> (raw)
In-Reply-To: <20170928143704.GC3611@e103592.cambridge.arm.com>
On Thu, Sep 28, 2017 at 03:37:04PM +0100, Dave Martin wrote:
> On Thu, Sep 28, 2017 at 03:14:47PM +0100, Will Deacon wrote:
> > On Thu, Sep 28, 2017 at 01:42:31PM +0100, Dave Martin wrote:
> > > On Thu, Sep 28, 2017 at 11:55:47AM +0100, Will Deacon wrote:
> > > > There are a couple of problems with the decodecode script and arm64:
> > > >
> > > > 1. AArch64 objdump refuses to disassemble .4byte directives as instructions,
> > > > insisting that they are data values and displaying them as:
> > > >
> > > > a94153f3 .word 0xa94153f3 <-- trapping instruction
> > > >
> > > > This is resolved by using the .inst directive instead.
> > > >
> > > > 2. Disassembly of branch instructions attempts to provide the target as
> > > > an offset from a symbol, e.g.:
> > > >
> > > > 0: 34000082 cbz w2, 10 <.text+0x10>
> > > >
> > > > however this falls foul of the grep -v, which matches lines containing
> > > > ".text" and ends up removing all branch instructions from the dump.
> > >
> > > Any idea why this doesn't affect other arches too ... or does it?
> >
> > I'm not sure, although I don't know how .inst works for architectures
> > with variable-length instructions and I *guess* the disassembly is less
> > fussy about data vs text for those targets.
>
> I rather meant the target disassembly for relative branches in the
> absence of labels.
>
> Anyway, I think this is at least harmless to other arches, and possibly
> helpful to them (if they disassemble those branch targets in the same
> sort of way).
Ah, I see what you mean. Something like the fixup below on top.
Will
--->8
diff --git a/scripts/decodecode b/scripts/decodecode
index 67214ec5b2cb..f1ec57c3cbf7 100755
--- a/scripts/decodecode
+++ b/scripts/decodecode
@@ -49,21 +49,14 @@ esac
disas() {
${CROSS_COMPILE}as $AFLAGS -o $1.o $1.s > /dev/null 2>&1
+ ${CROSS_COMPILE}strip $1.o
- if [ "$ARCH" = "arm" ]; then
- if [ $width -eq 2 ]; then
- OBJDUMPFLAGS="-M force-thumb"
- fi
-
- ${CROSS_COMPILE}strip $1.o
+ if [ "$ARCH" = "arm" -a $width -eq 2 ]; then
+ OBJDUMPFLAGS="-M force-thumb"
fi
- if [ "$ARCH" = "arm64" ]; then
- if [ $width -eq 4 ]; then
- type=inst
- fi
-
- ${CROSS_COMPILE}strip $1.o
+ if [ "$ARCH" = "arm64" -a $width -eq 4 ]; then
+ type=inst
fi
${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $1.o | \
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: mmarek@suse.cz, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] scripts/decodecode: Fix decoding for AArch64 (arm64) instructions
Date: Thu, 28 Sep 2017 19:01:35 +0100 [thread overview]
Message-ID: <20170928180135.GH9892@arm.com> (raw)
In-Reply-To: <20170928143704.GC3611@e103592.cambridge.arm.com>
On Thu, Sep 28, 2017 at 03:37:04PM +0100, Dave Martin wrote:
> On Thu, Sep 28, 2017 at 03:14:47PM +0100, Will Deacon wrote:
> > On Thu, Sep 28, 2017 at 01:42:31PM +0100, Dave Martin wrote:
> > > On Thu, Sep 28, 2017 at 11:55:47AM +0100, Will Deacon wrote:
> > > > There are a couple of problems with the decodecode script and arm64:
> > > >
> > > > 1. AArch64 objdump refuses to disassemble .4byte directives as instructions,
> > > > insisting that they are data values and displaying them as:
> > > >
> > > > a94153f3 .word 0xa94153f3 <-- trapping instruction
> > > >
> > > > This is resolved by using the .inst directive instead.
> > > >
> > > > 2. Disassembly of branch instructions attempts to provide the target as
> > > > an offset from a symbol, e.g.:
> > > >
> > > > 0: 34000082 cbz w2, 10 <.text+0x10>
> > > >
> > > > however this falls foul of the grep -v, which matches lines containing
> > > > ".text" and ends up removing all branch instructions from the dump.
> > >
> > > Any idea why this doesn't affect other arches too ... or does it?
> >
> > I'm not sure, although I don't know how .inst works for architectures
> > with variable-length instructions and I *guess* the disassembly is less
> > fussy about data vs text for those targets.
>
> I rather meant the target disassembly for relative branches in the
> absence of labels.
>
> Anyway, I think this is at least harmless to other arches, and possibly
> helpful to them (if they disassemble those branch targets in the same
> sort of way).
Ah, I see what you mean. Something like the fixup below on top.
Will
--->8
diff --git a/scripts/decodecode b/scripts/decodecode
index 67214ec5b2cb..f1ec57c3cbf7 100755
--- a/scripts/decodecode
+++ b/scripts/decodecode
@@ -49,21 +49,14 @@ esac
disas() {
${CROSS_COMPILE}as $AFLAGS -o $1.o $1.s > /dev/null 2>&1
+ ${CROSS_COMPILE}strip $1.o
- if [ "$ARCH" = "arm" ]; then
- if [ $width -eq 2 ]; then
- OBJDUMPFLAGS="-M force-thumb"
- fi
-
- ${CROSS_COMPILE}strip $1.o
+ if [ "$ARCH" = "arm" -a $width -eq 2 ]; then
+ OBJDUMPFLAGS="-M force-thumb"
fi
- if [ "$ARCH" = "arm64" ]; then
- if [ $width -eq 4 ]; then
- type=inst
- fi
-
- ${CROSS_COMPILE}strip $1.o
+ if [ "$ARCH" = "arm64" -a $width -eq 4 ]; then
+ type=inst
fi
${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $1.o | \
next prev parent reply other threads:[~2017-09-28 18:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 10:55 [PATCH] scripts/decodecode: Fix decoding for AArch64 (arm64) instructions Will Deacon
2017-09-28 10:55 ` Will Deacon
2017-09-28 12:42 ` Dave Martin
2017-09-28 12:42 ` Dave Martin
2017-09-28 14:14 ` Will Deacon
2017-09-28 14:14 ` Will Deacon
2017-09-28 14:37 ` Dave Martin
2017-09-28 14:37 ` Dave Martin
2017-09-28 18:01 ` Will Deacon [this message]
2017-09-28 18:01 ` Will Deacon
2017-09-29 10:07 ` Dave Martin
2017-09-29 10:07 ` Dave Martin
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=20170928180135.GH9892@arm.com \
--to=will.deacon@arm.com \
--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.