> On Tue, 8 Jan 2002, Richard Earnshaw wrote:
> 
> > 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.
> 
> Oh good.  In that case, we'll keep the syscall protocol as-is for ELF,
> except to change the SWI base to match our shiny new officially-assigned
> one, OK?

Yes, fine by me, but I think we should also state that any SWI made 
*directly* from thumb code is handled "as if" it were done as SYS_syscall 
(except that the immediate field of the thumb swi instruction is not used).

This way we only have to test that we are coming from thumb code to be 
able to set the CODE parameter to syscall() as SYS_syscall.

That would make the swi_entry sequence read:

ASENTRY_NP(swi_entry)
        PUSHFRAME

	tst	lr, #1			/* Is call from thumb?  */
        ldreq   r4, [lr, #-4]           /* ARM?: Get the SWI instruction */
	movne	r4, #SYS_syscall	/* Thumb?: Emulate as SYS_syscall */
        bic     r1, r4, #0xff000000     /* Extract the comment field */
        mov     r0, sp                  /* Pass the frame to any function 
*/
        bl      _C_LABEL(syscall)       /* It's a syscall ! */

Note that SYS_syscall is currently 0, so even after renumbering it should 
still be a valid immediate.

It is interesting to note that due to a missing optimization in the 
original code the above sequence is just one instruction longer, and on a 
strongarm should execute in the same time (because a load delay slot is 
now filled).

R.