[patch] More Arm EABI support routines

[Richard Earnshaw]

On Wed, 2005-10-26 at 19:53, Paul Brook wrote:
> On Monday 26 September 2005 14:46, Nick Clifton wrote:
> > Hi Paul,
> >
> > >>>>I'm in two minds about this.  Part of me thinks that this should be in
> > >>>>libgcc rather than newlib, since these are documented as part of the
> > >>>>standard run-time support for the compiler.
> 
> There are already other __aeabi_* routines in libc, so chances are you're 
> going to need more than just libgcc anyway.
> 

Most of those are part of the 'portable-runtime'.  It's important not to
confuse the two.  The portable runtime is a layer on top of a C library
interface that gives binary portability across a wide range of systems. 
The compiler support routines are completely separate (though they share
the same namespace).

> gcc will already generate calls to normal memcpy without user intervention.
> 

I'd like to make gcc generate calls to the __aeabi_mem* functions.  They
can be much more efficient, since they don't return an address and they
have extra known alignment information.

> > >>>My reason for putting them in libc was that they're then in the same
> > >>>place as the underlying mem* routines.
> > >>
> > >>But the whole point of these entry points is that they can be more
> > >>efficient than the mem* routines.  So long-term we really don't want to
> > >>implement them this way.
> > > Maybe. I was also thinking that the the C library is more likely to know
> > > about target specific properties (size/speed preference, coprocessor
> > > support/custom insns, etc) than libgcc.
> >
> > Nah - libgcc is built along with gcc for a specific target, so it
> > actually has a lot of target specific information built into it.  So
> > probably the best location for these sources is in gcc/config/arm
> > directory.  Then you need to find some way to insert the code into
> > libgcc.a.  You could recode the functions into assembler and then move
> > them into lib1funcs.asm.  Or you could create a t-arm-eabi file and have
> > it define LIB2ADD and then fix the arm-eabi pattern in config.gcc to
> > include this extra t-file.
> 
> This argument only really holds if you assume the exact target platform can be 
> statically determined by gcc.
> 
> As soon as you start trying to do dynamic selection you need C library 
> specific things to determine which target you're running on.  There is prior 
> art for doing this on glibc/linux.
> 
> We (CodeSourcery) have already added these routines to glibc, and expect them 
> to stay there for the reasons described above.
> Adding yet another implementation of memcpy in gcc for newlib targets seems 
> like a bad idea. I'd much prefer putting them in newlib so that all the 
> memcpy implementations are in the same place.

Writing 3 or four versions of __aeabi_mem*, each with a different
license doesn't seem particularly palatable, either.

R.