Subject: Re: RFC: Change SWI number base?
To: Ben Harris <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 01/13/2002 15:49:18
> 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:
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