ARM kprobes on Thumb kernels? was Re: Determining an ARM CPU's architecture

[Dave Martin]

On Tue, Jul 05, 2011 at 12:48:39PM -0400, Nicolas Pitre wrote:
> On Tue, 5 Jul 2011, Tixy wrote:
> 
> > On Tue, 2011-07-05 at 11:38 -0400, Nicolas Pitre wrote:
> > > On Tue, 5 Jul 2011, Tixy wrote:
> > > 
> > > > Irrespective of correct interworking behaviour and API issues, do we
> > > > think that it's a good memory saving exercise to not support probing ARM
> > > > code on Thumb kernels?
> > > 
> > > I would think so.  And if this is really something people need then this 
> > > could be revisited in the future.  Remember that you gain no points by 
> > > trying to submit everything on a zero-day.
> > 
> > There isn't really much lines of code or diffstat saving not supporting
> > ARM code on Thumb kernels. In fact, for cleanness reasons I would need
> > to reorganise code. Currently we have
> > 
> > kprobes.c
> > 	Infrastructure
> > kprobes-decode.c
> > 	ARM instruction decoding and simulation
> > 
> > My changes at the moment have
> > 
> > kprobes.c
> > 	Infrastructure (700 lines)
> > kprobes-decode.c
> > 	ARM instruction decoding and simulation (1000 lines)
> > 	Common instruction decoding and simulation (400 lines)
> > 	Decoding table processing (300 lines)
> > kprobes-thumb.c
> > 	Thumb instruction decoding and simulation (1500 lines)
> > 
> > To avoid #ifdef the ARM instruction decoding should be in its own file
> > and not built for Thumb kernels. So the minimal change would be to move
> > 
> > 	Common instruction decoding and simulation
> > 	Decoding table processing
> > 
> > into kprobes.c, or probably nicer into a new kprobes-common.c. (We could
> > then rename kprobes-decode to kprobes-arm and have things looking neat.)
> > 
> > As this is reworking 70 patches, I would like confirmation that the
> > approach is good before starting ;-)
> 
> Sure, looks sensible.  Better do the renaming first and only add new 
> stuff to it with subsequent patches.
> 
> Keeping the kprobes interface separate from the actual table and 
> simulation/emulation handling is certainly a good idea too. So you'd end 
> up with kprobes.c, kprobes-common.c, kprobes-arm.c and kprobles-thumb.c.

That sounds good to me if it's straightforward to achieve.

Cheers
---Dave