linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tixy@linaro.org (Jon Medhurst (Tixy))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: kprobes: Fix test code compilation errors for ARMv4 targets
Date: Tue, 25 Mar 2014 14:54:44 +0000	[thread overview]
Message-ID: <1395759284.3478.88.camel@linaro1.home> (raw)
In-Reply-To: <6485768.fvJS4nr3cP@wuerfel>

On Tue, 2014-03-25 at 14:42 +0100, Arnd Bergmann wrote:
> On Tuesday 25 March 2014 09:27:29 David Long wrote:
> > On 03/11/14 12:54, Jon Medhurst wrote:
> > > Conditionally compile kprobes test cases for ARMv5 instructions to avoid
> > > compilation errors with ARMv4 targets like:
> > >
> > > /tmp/cc7Tx8ST.s:16740: Error: selected processor does not support ARM mode `clz r0,r0'
> > >
> > > Signed-off-by: Jon Medhurst <tixy@linaro.org>
> > 
> > This looks OK to me.  Feel free to add my ack.
> 
> Ah, I had a similar patch in my 'randconfig-fixes' series.

Where's that?

>  I noticed three
> other configurations that are broken with kprobes-test:
> 
> - ARMv3 (enabled by ARCH_RPC)

Didn't know we support < ARMv4!

> - ARMv7-M (enabled by ARCH_EFM32)

I guess that problem is because randconfig is enabling HAVE_KPROBES,
even though it wouldn't normally be selected, because we have

   config ARCH_ARM
	select HAVE_KPROBES if !XIP_KERNEL

and ARCH_EFM32 is XIP_KERNEL.

I think this problem goes all the way back to the commit which added
HAVE_KPROBES to all arches (3f550096dede4430f83b16457da83bf429155ac2)
That replaced 

   config KPROBES
	depends on ... (ARM && !XIP_KERNEL)

with the current select if !XIP_KERNEL, which made it possible to enable
kprobes for XIP when before we couldn't. And presumably that was for a
good reason like it doesn't work on XIP?

Not sure at the moment how best to fix that. (Making ARM_KPROBES_TEST
depend on !XIP_KERNEL doesn't solve the underlying problem of KPROBES
feature still being enabled for XIP kernels.)

> - CPU_ENDIAN_BE32 (enabled by building a big-endian kernel on ARMv5 or older)

> Should we treat those the same way, or just disable Kprobes for this case
> if nobody cares?

For CPU_ENDIAN_BE32 I have a feeling that the kprobes code wouldn't
work, would have to think more about why I have that feeling. If it
doesn't, we come back to the problem that arch code can't add
dependencies to CONFIG_KPROBES as things stand.

-- 
Tixy

  reply	other threads:[~2014-03-25 14:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 16:54 [PATCH 0/3] Fixes for kprobes test issues Jon Medhurst
2014-03-11 16:54 ` [PATCH 1/3] ARM: kprobes: Prevent known test failures stopping other tests running Jon Medhurst
2014-03-24 15:18   ` David Long
2014-03-24 16:49     ` Jon Medhurst (Tixy)
2014-03-24 16:56       ` Russell King - ARM Linux
2014-03-24 18:34         ` David Long
2014-03-25 14:02           ` Russell King - ARM Linux
2014-03-25 14:08             ` David Long
2014-03-25 14:20               ` Jon Medhurst (Tixy)
2014-03-11 16:54 ` [PATCH 2/3] ARM: kprobes: Disallow instructions with PC and register specified shift Jon Medhurst
2014-03-24 19:49   ` David Long
2014-03-25 12:51     ` Jon Medhurst (Tixy)
2014-03-11 16:54 ` [PATCH 3/3] ARM: kprobes: Fix test code compilation errors for ARMv4 targets Jon Medhurst
2014-03-25 13:27   ` David Long
2014-03-25 13:42     ` Arnd Bergmann
2014-03-25 14:54       ` Jon Medhurst (Tixy) [this message]
2014-03-25 15:17         ` Arnd Bergmann

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=1395759284.3478.88.camel@linaro1.home \
    --to=tixy@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 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).