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 15:14:47 +0100 [thread overview] Message-ID: <20170928141447.GA27788@arm.com> (raw) In-Reply-To: <20170928124206.GA3611@e103592.cambridge.arm.com> 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. > > This patch resolves both issues by using the .inst directive for 4-byte > > quantities on arm64 and stripping the resulting binaries (as is done on > > arm already) to remove the mapping symbols. > > > > Signed-off-by: Will Deacon <will.deacon@arm.com> > > > > --- > > scripts/decodecode | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/scripts/decodecode b/scripts/decodecode > > index d8824f37acce..67214ec5b2cb 100755 > > --- a/scripts/decodecode > > +++ b/scripts/decodecode > > @@ -58,6 +58,14 @@ disas() { > > ${CROSS_COMPILE}strip $1.o > > fi > > > > + if [ "$ARCH" = "arm64" ]; then > > + if [ $width -eq 4 ]; then > > + type=inst > > Can we merge with arm here, or does arm still support toolchains that > don't have .inst? Anyway, no big deal. I thought we still supported those, so I'd be reluctant to merge the clauses unless it's broken (the script works as-is for me with arm). I'm also not sure what we should do for 16-bit Thumb-2 encodings, where we have inst.n and inst.w to contend with. > > + fi > > + > > + ${CROSS_COMPILE}strip $1.o > > + fi > > + > > ${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $1.o | \ > > grep -v "/tmp\|Disassembly\|\.text\|^$" > $1.dis 2>&1 > > FWIW, > > Reviewed-by: Dave Martin <Dave.Martin@arm.com> Thanks! Will
WARNING: multiple messages have this Message-ID (diff)
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 15:14:47 +0100 [thread overview] Message-ID: <20170928141447.GA27788@arm.com> (raw) In-Reply-To: <20170928124206.GA3611@e103592.cambridge.arm.com> 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. > > This patch resolves both issues by using the .inst directive for 4-byte > > quantities on arm64 and stripping the resulting binaries (as is done on > > arm already) to remove the mapping symbols. > > > > Signed-off-by: Will Deacon <will.deacon@arm.com> > > > > --- > > scripts/decodecode | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/scripts/decodecode b/scripts/decodecode > > index d8824f37acce..67214ec5b2cb 100755 > > --- a/scripts/decodecode > > +++ b/scripts/decodecode > > @@ -58,6 +58,14 @@ disas() { > > ${CROSS_COMPILE}strip $1.o > > fi > > > > + if [ "$ARCH" = "arm64" ]; then > > + if [ $width -eq 4 ]; then > > + type=inst > > Can we merge with arm here, or does arm still support toolchains that > don't have .inst? Anyway, no big deal. I thought we still supported those, so I'd be reluctant to merge the clauses unless it's broken (the script works as-is for me with arm). I'm also not sure what we should do for 16-bit Thumb-2 encodings, where we have inst.n and inst.w to contend with. > > + fi > > + > > + ${CROSS_COMPILE}strip $1.o > > + fi > > + > > ${CROSS_COMPILE}objdump $OBJDUMPFLAGS -S $1.o | \ > > grep -v "/tmp\|Disassembly\|\.text\|^$" > $1.dis 2>&1 > > FWIW, > > Reviewed-by: Dave Martin <Dave.Martin@arm.com> Thanks! Will
next prev parent reply other threads:[~2017-09-28 14:14 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 [this message] 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 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=20170928141447.GA27788@arm.com \ --to=will.deacon@arm.com \ --cc=Dave.Martin@arm.com \ --cc=akpm@linux-foundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mmarek@suse.cz \ /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: linkBe 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.