[PATCH 1/4] ARM: ftrace: use canonical Thumb-2 wide instruction format

[Bi Junxiao]

on 11/23/2011 10:42 PM Dave Martin wrote:
> On Tue, Nov 22, 2011 at 11:30:11PM +0530, Rabin Vincent wrote:
>    
>> On Tue, Nov 22, 2011 at 17:32, Dave Martin<dave.martin at linaro.org>  wrote:
>>      
>>> On Mon, Nov 21, 2011 at 08:43:46PM +0530, Rabin Vincent wrote:
>>>        
>>>> +#ifndef __ARMEB__
>>>> +     if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
>>>> +             old = (old>>  16) | (old<<  16);
>>>> +             new = (new>>  16) | (new<<  16);
>>>>          
>>> I think swahw32() in<linux/swab.h>  can be used for this operation.
>>>        
>> Yes.
>>
>>      
>>> Really though, we need a common set of "load and store instruction"
>>> macros, rather than duplicating this knowledge everywhere.
>>>        
>> Yes, though this ftrace code may not be able to use them directly since
>> it uses probe_kernel_read()/write().
>>      
> In that case what we would want are macros to convert instructions between
> integer and in-memory representation, rather than conflating all that
> together in some memory accessor macros.
>
> How about:
>
> #include<linux/swab.h>
>
> #ifdef __ARMEB__
> #define insn_to_mem_arm(insn) swab32(insn)
> #define insn_to_mem_thumb16(insn) swab16(insn)
> #define insn_to_mem_thumb32(insn) swab16(insn)
> #else
> #define insn_to_mem_arm(insn) (insn)
> #define insn_to_mem_thumb16(insn) (insn)
> #define insn_to_mem_thumb32(insn) shahw32(insn)
> #endif
>
> #define mem_to_insn_arm(insn) insn_to_mem_asm(insn)
> #define mem_to_insn_thumb16(insn) insn_to_mem_thumb16(insn)
> #define mem_to_insn_thumb32(insn) insn_to_mem_thumb32(insn)
>
> Because these are all straightforward swap operations, we don't really
> need separate forwards and backwards operations, but having the separate
> names may make calling code easier to read.
>
> I'm still not sure exactly which header this belongs in, but it's a core
> ARM thing; not local to kprobes or ftrace, etc.
>
>    
Yes, these macros are useful for be8 support. Do they deserve a 
separated header file as there is no appropriate one for them now?
> If this looks sensible, it would also make sense for Junxiao Bi to build
> his big-endian fixes on it.
>
> Cheers
> ---Dave
>
>