> 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;
...