Richard Earnshaw wrote:
> 
> > 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

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

Ok - I've only written for ARM, and not considered the joys of
interworking, nor any of the 'veneer' code that the linker might
(hopefully) insert.

Presumably the return sequence has to be 'bx lr', rather than anything
else?  Or will the cpu leap to thumb if a normal instruction loads an
odd pc?
> 
> 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.

Ah!  You are giving the user access to this symbol, not just the
compiler.
> 
> 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.
>
Yes: The compiler definitely nees to reference the _arm... symbol.

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

Agreed...

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

I wonder sometimes if there should be an option to force references to
hit the 'reserved' part of the namespace.  It is too easy to forget,
when writing library code, to explicitely add an '_' to all the
functions from system header files that are not defined by POSIX!

	David