Subject: Re: RFC: Change SWI number base?
To: None <email@example.com>
From: David Laight <David.Laight@btinternet.com>
Date: 01/08/2002 18:31:24
> 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
> bx pc /* Switch to arm code */
> .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).