[RFC PATCH] ARM: fiq: Refactor {get,set}_fiq_regs() for Thumb-2

[Frank Hofmann]

On Fri, 8 Apr 2011, Dave Martin wrote:

> On Thu, Apr 7, 2011 at 11:28 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Thu, Apr 07, 2011 at 11:02:18AM +0100, Dave Martin wrote:
>>> The main reason for that is to code the ->ARM_r8 in C (as in the
>>> existing code).  I feel safer doing that than hard-coding an offset in
>>> the assembler, though possibly that is overkill since if the layout of
>>> struct pt_regs changes we are probably in trouble for all kinds of
>>> other reasons anyway...
>>
>> It may be worth looking up exactly what's allowed with naked functions.
>> A naked function tells the compiler to omit the function prologue and
>> epologue, which effectively means you can't do very much other than
>> inline asm in them.  So I think we're pretty safe from register
>> allocation issues.
>>
>> If the compiler was to do register allocation for &regs->ARM_r8, and it
>> landed up in r8, then that would not only break the code, but also break
>> the ABI as the compiler would be unable to save the value of r8.
>>
>>> I could have used register variables with explicit register
>>> assignments.  Alternatively, I could have added r8-r14 to the clobber
>>> list -- but then the compiler would generate unnecessary save and
>>> restore sequences for all those registers.
>>
>> I doubt it would for a naked function.  You're expected to handle
>> that stuff yourself with such things.
>>
>
> It looks like your instinct is correct -- if I add those extra
> registers to the clobber list, I get no save/resrote sequences, as you
> suggest... but...

Just some observation on inline assembly behaviour ...

If gcc in its wisdom decides it wants a register, it'll take that 
register, in the sense that a clobber list r0-r12 will make compiles fail 
even if gcc theoretically were able to restore every item from the stack 
and/or first principles. But if you leave it a way out, then imagine 
the compiler deciding to want your R8 reg, and doing code like:

 	mov	r12, r8
 	... your inline assembly goes here
 	mov	r8, r12

because you left it a nonclobbered register to store things in ...

I've tried that once, with inline assembly that had a "ldm r0,{r0-r14}" 
and the whole function operated on nothing else at all but global 
variables. gcc wanted to keep the global pointer in a reg, and refused to 
re-load that reg after that ldm, and whinced about the compile when giving 
it a "full" clobber list".


Anyway, re __naked: See <linux/compiler-gcc.h> for the goodie:

/*
  * it doesn't make sense on ARM (currently the only user of __naked) to trace
  * naked functions because then mcount is called without stack and frame pointer
  * being set up and there is no chance to restore the lr register to the value
  * before mcount was called.
  */
#define __naked                         __attribute__((naked)) notrace

who knows what other nice autoextensions beyond -finstrument-functions gcc 
ultimately will come up with are going to have effects that end up 
"clothing" naked functions nicely.


In the end, fully agree that Dave is right, an assembler sourcefile is the 
best place.

FrankH.

>
> From the GCC info docs:
> `naked'
>     Use this attribute on the ARM, AVR, IP2K and SPU ports to indicate
>     that the specified function does not need prologue/epilogue
>     sequences generated by the compiler.  It is up to the programmer
>     to provide these sequences. The only statements that can be safely
>     included in naked functions are `asm' statements that do not have
>     operands.  All other statements, including declarations of local
>     variables, `if' statements, and so forth, should be avoided.
>     Naked functions should be used to implement the body of an
>     assembly function, while allowing the compiler to construct the
>     requisite function declaration for the assembler.
>
> ... but we don't have an asm statement with no operands and no
> accompanying declarations in this case.  Logically the code ought to
> work if the compiler doesn't spill anything to the stack, and explicit
> register variables ought to avoid this provided we don't have too
> many.
>
> But I doubt whether this behaviour is well tested by the compiler guys.
>
> Cheers
> ---Dave
>