Re: Kprobes Support for ARM arch

[rsmadhvesh@vsnl.net]

Quentin Barnes wrote on Saturday, January 13, 2007 1:32 am
> >Hi All,
> >
> >Recently we completed the kprobes support for ARM architecture
> >targetted at 2.6.16 kernel. I have uploaded these patches in the 
> >below CELF wiki page along with few test programs.
> >This implementation is tested using 2.6.16-24 kernel for 
> >OMAP5912 OSK reference platform. 
> >
> >The patch is available in the below CELF wiki page
> >http://tree.celinuxforum.org/CelfPubWiki/PatchArchive
> >
> >The patch can be downloaded directly from here
> >http://tree.celinuxforum.org/CelfPubWiki/PatchArchive?action=AttachFile&do=get&target=kprobes-arm-patches-2.6.16.24.tgz
> >
> >This implementation supports only kprobes and doesnot
> >support any other variants like jprobes, kretprobes etc.
> >Also it doesnot support branch/jump instructions probing.
> >
> >I noticed some discussions regarding ARM kprobes in the
> >archive. We are open to suggestions and how this implementation can
> >be improved. 
> 
> Abhishek Sagar and I have been working together on a joint ARM
> kprobes effort for some time.
> 
> We have kprobes, jprobes, kretprobes, and boosting support(*)
> hobbling along now for ARM.  The port is also SMP clean and
> preemption safe.  It is ported against 2.6.19.1.  We're pretty much
> code complete and doing cleanup, some manual optimizations, and
> testing now.  We're planning on releasing our patch probably about
> the end of this month.
> 
> If you like, I can send you our work-in-progress for your review.
Quite interesting, it may be good idea to combine the kprobes
ARM code and start discussions on how it can be pushed
to main line kernel. Ananth in his previous mail pointed out 
few interface changes in latest kernel for kprobes. Our kprobes
support was immediately required for 2.6.16-x kernel, so we started
with that kernel. Now i start checking for main line kernel changes and
we can merge and get it reviewed by ARM experts in arm-mail 
list and then it can be pushed for main line kernel.

> *) The boosting model I've implemented is not the standard boosting
>   model, but it effectively does the same thing my eliminating the
>   second breakpoint exception.  This approach works in all cases,
>   not for just some instructions, so the second breakpoint is never
>   necessary.
> 

-Madhvesh