Re: [patch] More Arm EABI support routines

[Paul Brook <paul at codesourcery dot com>]

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.

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

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

Paul