> 
> The trampoline generating code in gcc 
> really needs to generate an inline SWI IMB rather than calling a function 
> Having to jump around an alignment and a constant is so gross that I 
> wouldn't even begin to contemplate doing this....  It wouldn't be quite so 
> bad if this hack didn't cross the user-kernel boundary, but mandating such 
> a specification across that boundary is truly awful.
true: Specially since the compiler would have to do it, not some 'hand
crafted, system dependent as, file'.
 
I didn't know about these trampolines....
Is it worth defining a thumb swi (1 of 256) just for this piece of code?

I guess this means the swi code does have to check for thumb mode after all.

> 
> The more I think about it, the more I suspect that the final stub into the 
> kernel should be coded in ARM code rather than thumb code.  That makes 
> this whole issue go away for the normal case, and we should stick to using 
> the current technique of normally coding the SWI number in the 
> instruction.  For the few rare cases where we must use a thumb SWI (eg the 
> compiler for an IMB -- switching into and out of ARM code inline is just 
> too nasty to contemplate here), then we should just specify that a Thumb 
> SWI is always coded such that the SWI-code is passed in r0.
> 
> In other words, the thumb SWI entry sequence is
> 
> .code 16
> .align 0
> SWI_nnn:
> bx pc /* Switch to arm code */
> nop
> .code 32
> swi nnn
> ldrcs ip, L__cerror
> bxcc lr /* Return if no error */
> bx ip

Yes - fairly neat.  Need to get the alignment right though.
think that requires a .align 2 (or a .balign 4), and a sanity check!

pull the 'bxcc lr' up an instruction...

Probably shorter than many thumb sequences to get the 32bit constant
somewhere sensible (ok not much longer).

    David