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

[Tixy]

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 ;-)

-- 
Tixy