All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is endian-agnostic
Date: Thu, 25 Jul 2013 18:54:56 +0100	[thread overview]
Message-ID: <20130725175456.GF2546@localhost.localdomain> (raw)
In-Reply-To: <51F14CAF.5010602@codethink.co.uk>

On Thu, Jul 25, 2013 at 05:05:03PM +0100, Ben Dooks wrote:
> On 25/07/13 16:57, Dave Martin wrote:
> >On Thu, Jul 25, 2013 at 03:42:36PM +0100, Ben Dooks wrote:
> >>Currently BUG() uses .word or .hword to create the necessary illegal
> >>instructions. However if we are building BE8 then these get swapped
> >>by the linker into different illegal instructions in the text.
> >
> >In the case of Thumb, the resulting instruction is actually not illegal,
> >which is even worse...
> >
> >>Change to using .inst and .inst.w to create the instructions and mark
> >>them as instructions so that the linker acts correctly.
> >>
> >>Signed-off-by: Ben Dooks<ben.dooks@codethink.co.uk>
> >>---
> >>  arch/arm/include/asm/bug.h |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> >>index 7af5c6c..b95da52 100644
> >>--- a/arch/arm/include/asm/bug.h
> >>+++ b/arch/arm/include/asm/bug.h
> >>@@ -12,10 +12,10 @@
> >>   */
> >>  #ifdef CONFIG_THUMB2_KERNEL
> >>  #define BUG_INSTR_VALUE 0xde02
> >>-#define BUG_INSTR_TYPE ".hword "
> >>+#define BUG_INSTR_TYPE ".inst.w "
> >>  #else
> >>  #define BUG_INSTR_VALUE 0xe7f001f2
> >>-#define BUG_INSTR_TYPE ".word "
> >>+#define BUG_INSTR_TYPE ".inst "
> >>  #endif
> >
> >There was some uncertainty a while ago about precisely which versions of
> >gas support .inst.
> >
> ><asm/opcodes.h>  implements an abstracted workaround for this issue,
> >whereby you can emit instructions using the __inst*() macros, and
> >the swabbing and assembler directives should be generated for you.
> >
> >The patch below ought to do this for BUG(), but I've only briefly
> >build-tested it.
> >
> >
> >Note that the disassembly of the injected instructions in .o files
> >can be a bit confusing, because they are marked as data, do ld --be8
> >doesn't swab them (unlike the instructions, which do get swabbed).
> >objdump may also do extra swabbing during disassembly.
> >
> >You can sanity-check what is really in the image by dumping the text
> >section of vmlinux with objdump -s.
> >
> >
> >The change to<asm/opcodes.h>  is due to a missing include which is
> >really required for correctness, but which didn't show up without
> >the<asm/bug.h>  change (this causes opcodes.h to get included way
> >more often than is otherwise the case).
> >
> >Cheers
> >---Dave
> 
> Given it was added ~2006 according the mailing lists I have seen, then
> it should be ok to use for building modern kernels with. I think the
> use of .inst and .inst.w is a better solution than having the code
> having bits of it marked as data.

Of course it is.  But this discussion can be decoupled from bug.h:
if we decide to migrate to .inst, we can do that in one place in
opcodes.h, no?

Otherwise, we have multiple fixes to apply when we decide to make
that change.

Cheers
---Dave

  reply	other threads:[~2013-07-25 17:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 14:42 BUG() issues with big-endian Ben Dooks
2013-07-25 14:42 ` [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is endian-agnostic Ben Dooks
2013-07-25 15:57   ` Dave Martin
2013-07-25 16:05     ` Ben Dooks
2013-07-25 17:54       ` Dave Martin [this message]
2013-07-26 10:48         ` Dave Martin
2013-07-25 14:42 ` [PATCH 2/2] ARM: fix BUG() detection Ben Dooks

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=20130725175456.GF2546@localhost.localdomain \
    --to=dave.martin@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.