Subject: Re: Shared library support for ARM ELF
To: Ben Harris <firstname.lastname@example.org>
From: Richard Earnshaw <email@example.com>
Date: 07/23/2001 11:07:15
> 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
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
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); 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.
 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.