> > the swi they could be done in asm see page A9-12 of the ARM ARM, it's shows 
> > how to get the right number out for either thumb or arm, so with the same 
> > text you can move the tf_pc appropriatly.
> 
> It's possible, but since it does all the magic after (effectively) saving
> the trapframe, it's not much of an improvement on my plan (though it does
> have the virtue of keeping the entry to C clean).  I suspect my enthusiasm
> for writing things in C rather than assembler may be influencing me here.
> 
> > Something of note is that it shows that thumb only allows for 256 swi codes, 
> > I believe that netbsd has 512 syscalls at the mo, looks like some kind of 
> > magic might be needed to make thumb cope with that....
> 
> Well, that could be claimed to be what syscall 0 (syscall()) is for.  It'd
> require a bit of magic in the syscall stubs, but it wouldn't be too
> painful.  You'd need to have each stub (for syscalls > 255) look something
> like this:
> 
> LSYS_foo:
> 	.word	SYS_foo
> foo:
> 	push	{r0-r3}
> 	pop	{r1-r3}
> 	ldr	r0, LSYS_foo
> 	swi	SYS_syscall
> 	add	sp, #4
> 	bcs	cerror
> 	bx	r14

Unless you are really trying to save space, there's no real need for the syscall functions to be compiled as thumb code.  Just make them ARM code and ensure that calling to and returning from them supports interworking.

One minor mistake in your code example: you can't use a negative offset in a pc-relative load in Thumb, so your constant would have to appear after the stub, not before it.

R.