RE: Update newlib to support efficient string operation functions for Thumb.

["Hale Wang" <Hale dot Wang at arm dot com>]

Hi Corinna,

I have done several test locally and found that maybe we can't just leave this wrapper blank. If we do this, the arm-none-eabi-gcc will report "undefined reference to `strlen` ".

The reason is that the libc/machine/arm/lib_a-strlen.o will always be generated even if we don't define this function, and this *.o will replace the default libc/string/lib_a-strlen.o.

The details are describled as following:
	1. The libc.a is generated by the following scripts:
	    ===================================
	        for  i  in string/lib.a  machine/lib.a;  do \
		arm-none-eabi-ar x ../$i; \
  	        done; \
	    arm-none-eabi-ar  rc  ../libc.a  *.o
	    arm-none-eabi-ranlib  libc.a
	    ===================================
	2. Firstly, lib_a-strlen.o is generated by the script ' arm-none-eabi-ar  x  string/lib.a '. And the default strlen() function is defined in this object file.
	3. Then, another lib_a-strlen.o is generated by the script ' arm-none-eabi-ar  x  machine/lib.a '. This file will replace the previous object file immediately because they own the same name. And no function is defined in this object file.
	4. Finally, strlen() is not defined in the libc.a generated. This will cause the link failure.

So we may need to turn back to our previous patch.

Thanks and Best Regards,
Hale Wang

> -----Original Message-----
> From: Hale Wang [mailto:Hale.Wang@arm.com]
> Sent: 2014å8æ15æ 13:42
> To: newlib@sourceware.org; 'vinschen@redhat.com'
> Subject: RE: Update newlib to support efficient string operation functions for
> Thumb.
> 
> Hi Corinna,
> 
> I agree. I just need to leave the wrapper blank. The libc/string/ will be
> automatically pulled in as the default definition.
> 
> Thanks for your command. I will update this patch and do some testing locally
> before I send it out.
> 
> Thanks and Best Regards,
> Hale Wang
> 
> > -----Original Message-----
> > From: newlib-owner@sourceware.org [mailto:newlib-
> > owner@sourceware.org] On Behalf Of Corinna Vinschen
> > Sent: 2014å8æ14æ 16:28
> > To: newlib@sourceware.org
> > Subject: Re: Update newlib to support efficient string operation
> > functions for Thumb.
> >
> > Hi Hale,
> >
> > On Aug 14 12:14, Hale Wang wrote:
> > > Hi,
> > >
> > > The source files in newlib/libc/machine/arm/ are not so efficient
> > > enough to sopport Thumb.
> > >
> > > For Cortex-M0, if we don't define '__OPTIMIZE_SIZE__' or
> > > 'PREFER_SIZE_OVER_SPEED' which means size is not preferred,
> > > inefficient code will be used. This may result in pool benchmark
> > performance.
> > >
> > > In this case, we can include newlib/libc/string/strcmp.c to improve
> > > the performance. And if size is preferred, the original code will be used.
> > >
> > > I have done some tests on Dhrystone benchmark, and the performance
> > > of
> > > Cortex-M0 can be improved to 13% with this solution.
> > >
> > > The strlen.c can be improved in the similar way.
> > >
> > > Bootstrap and no make check regression on X86-64.
> >
> > This patch is a bit complicated.  You're explicitely including
> > ../../string/*.c, but that's not necessary.  What you should do is
> > this:  Use #if to define the scenario in which the assembler code should not
> be used:
> >
> >   # if [thumb1 && no-size-opimization]
> >
> >     [code here]
> >
> >   #endif
> >
> > The result is that the strlen/strcmp functions won't be defined in the
> > assembler-optimized files, and that will automatically pull in the
> > default C definitions of strlen/strcmp from libc/string.  No reason to
> > include them explicitely.
> >
> > Along the same lines, the strcmp-stub.c file should not be necessary.
> > Just don't define the strcmp() function in the assembler file in the
> > scenario you don't want it, and newlib will fall back to the C
> > function defined in libc/string/strcmp.c.
> >
> >
> > Corinna
> >
> > --
> > Corinna Vinschen
> > Cygwin Maintainer
> > Red Hat