[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1414493894.1433.1.camel@linaro.org>
Date: Tue, 28 Oct 2014 10:58:14 +0000
From: "Jon Medhurst (Tixy)" <tixy@...aro.org>
To: Wang Nan <wangnan0@...wei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
linux@....linux.org.uk, will.deacon@....com, dave.long@...aro.org,
taras.kondratiuk@...aro.org, Ben Dooks <ben.dooks@...ethink.co.uk>,
Christoph Lameter <cl@...ux.com>, Rabin Vincent <rabin@....in>,
"David S. Miller" <davem@...emloft.net>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Li Zefan <lizefan@...wei.com>
Subject: Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On Mon, 2014-10-27 at 17:17 +0000, Jon Medhurst (Tixy) wrote:
[...]
> The decode table could possibly incorporate patterns to
> cover instructions types that you split up in PATCH 1, e.g. so we
> might not need separate PROBES_STORE and PROBES_STORE_EXTRA (
Sorry, I got that a bit wrong, the first patch only splits loads and
stores and doesn't create create any new 'extra' instruction types.
However, my comment could still apply to that split between between
loads and stores; for many of them, the difference is just a single bit
that is possibly cheap or free to test in the checkers.
The reason I am thinking along these lines is that each additional enum
value in the instruction types adds an entry into every action and
checker table, as well as expanding the decoding tables to detect them.
So I just want to make sure that we think these additions result in a
net benefit in code size and complexity.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists