> On Sun, 22 Jul 2001, Richard Earnshaw wrote:
> 
> > > any additional routines in libarm32?  Should that be renamed libarm?
> 
> I'd be kind of reluctant to rename an existing library.

libarm32 could be made into a symlink to libarm.

> > In order to make trampolines work correctly, the compiler really needs to
> > make use of the cache synchronization function.  Having it as a function
> > in libarm is a pain, since it means that either the compiler must emit the
> > SWI call directly, or libarm must be linked into every program on the
> > off-chance that it might use trampolines.  How about having
> > __arm_sync_icach() (note preceeding underscores) in libc?  It could be
> > exactly the same as the libarm version.
> 
> Alternatively, ARM specify a SWI to use for this (IMB), so why not make it
> work and have GCC emit it?
> 

A good suggestion, however, that brings up another issue if we ever want 
to support Thumb (which I'd like to see sometime).

The SWI space in the thumb instruction only allows for 256 SWI calls, but 
we already have more than that number of syscall entries.  That means that 
either
1) We have to switch into ARM mode before making a syscall (well, if 
making a syscall to a swi higher than 255); then we have to switch back 
again afterwards.
2) We need to have a new mechanism for passing the syscall number.

One solution for 2 would be to pass the syscall number in r0 (or some 
other register -- ip might be a good choice[1]); this might even be more 
efficient, since then the kernel doesn't have to grub around decoding the 
instruction to see which SWI is being executed.

Thoughts?

R.

[1] putting the SWI code in r0 might mean shuffling any arguments passed 
in registers, so moving the inefficiency from the kernel to the library; 
but ip is difficult to set in thumb mode.