[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.58.1110131205410.7452@infra-view9.cisco.com>
Date: Thu, 13 Oct 2011 12:16:27 -0700 (PDT)
From: Victor Kamensky <kamensky@...co.com>
To: Ralf Baechle <ralf@...ux-mips.org>
cc: David Daney <david.daney@...ium.com>, manesoni@...co.com,
linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org,
ananth@...ibm.com
Subject: Re: [PATCH] MIPS Kprobes: Support branch instructions probing
On Thu, 13 Oct 2011, Ralf Baechle wrote:
> On Thu, Oct 13, 2011 at 10:28:51AM -0700, David Daney wrote:
>
> > Where is the handling for:
> >
> > case cop1_op:
> >
> > #ifdef CONFIG_CPU_CAVIUM_OCTEON
> > case lwc2_op: /* This is bbit0 on Octeon */
> > case ldc2_op: /* This is bbit032 on Octeon */
> > case swc2_op: /* This is bbit1 on Octeon */
> > case sdc2_op: /* This is bbit132 on Octeon */
> > #endif
> >
> > These are all defined in insn_has_delayslot() but not here.
David, nice catch!
> Which is a wonderful demonstration for why duplicating such a large
> function from branch.c was a baaad thing to do.
>
> Maneesh, can you refactor the code to share everything that was copied
> from __compute_return_epc() can be shared with kprobes? Idealy make
> everything a two part series, first one patch to refactor branch.c
Yes, it does make a lot of sense. Don't you think we need to do
EXPORT_SYMBOL for __compute_return_epc as well? So it could be used by
klms.
Actually we have yet another copy of it in mips uprobes code, which
normally is built as klm, if we refactor and export __compute_return_epc
all three places could use the same function.
Thanks,
Victor
> and
> the 2nd patch to deal with kprobes.
>
> Thanks,
>
> Ralf
>
--
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