Subject: Re: RFC: Change SWI number base?
To: David Laight <david@wheelbarrow.l8s.co.uk>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm
Date: 01/14/2002 13:47:26
> Richard Earnshaw wrote:
> >
> > >
> > > I don't think there will be many cases where we will need to call a SWI
> > > directly from thumb. Indeed the only case I can readily think of is the
> > > compiler generating an IMB (for which it would be tricky to make it switch
> > > into and out of ARM mode).
> >
> > Of course, an even cleaner solution would be to provide weak versions of
> >
> > arm_drain_writebuf
> > arm_sync_icache
> >
> > (note I've dropped the '32') directly in libc, so that the compiler can
> > just call the library function.
> >
> > [ They have to be weak since they aren't part of posix -- maybe we should
> > also provide full symbols _arm_drain_writebuf etc that the compiler can
> > use as alternate entry points ]
>
> Presumably you need separate arm and thumb symbols?
> Or are there separate arm and thumb libc? and no support for 'mixed'
> binaries?
No, in the same way as you don't need duplicates for any libc symbol. A
library will normally contain either ARM code or Thumb code. Clearly to
support Thumb an ARM build will have to be built with interworking enabled
(so that return sequences will switch modes correctly) but the calling
side is handled by the linker which needs to insert an interworking veneer
if necessary.
Normally I would expect libraries to be built as ARM code.
> Both names should be places firmly in the 'reserevd for the
> implementation' namespace. Even then that is cluttered badly.
The implementation in the "public" namespace is there to satisfy the
documented interfaces in the manual. Since it isn't part of ANSI/POSIX it
must be a weak symbol so that the user can override it.
The compiler should use implemenation in the reserved name space (ie
_arm...) so that the definition it sees doesn't change if the user happens
to override the weak implementation. This is why we need both.
> Making the symbols 'weak' helps nobody!
Making the symbol weak allows libc to provide a function that isn't part
of the standard without violating the requirement of the standard that
other functions can be defined by the user. Making the public interface
weak solves exactly the problem we have here.
> If a user does define one his
> application just dies terribly and he doesn't know why. At least he (is
> likely to) get a link error if they are not weak (unless he defines an
> uninitialised common item).
I believe that what we want is exactly the same as several interfaces
already in libc, eg:
#ifdef __weak_alias
__weak_alias(isatty,_isatty)
#endif
int
isatty(fd)
int fd;
...