Update newlib to support efficient string operation functions for Thumb.

[Hale Wang]

Hi Jeff,

Thank you very much for your solution. It is really helpful.

I used your commands to do some tests and found an automake issue about the parameter multi-definitions.

The commands in Makefile.am:
================================
STRCMP_SRC=strcmp.S
STRCMP_OBJ=$(lpfx)strcmp.o

if HAVE_THUMB1
if OPT_SIZE
else
STRCMP_SRC=
STRCMP_OBJ=
endif
endif
================================

So we expect the STRCMP_SRC and STRCMP_OBJ to be overridden if HAVE_THUMB1 is defined and OPT_SIZE is not defined.

Call the command "automake  --add-missing" to regenerate the Makefile.in. Some warnings are reported like "`STRCMP_SRC` was already defined in condition TRUE". 

The command generated in Makefile.in:
================================
@HAVE_THUMB1_FALSE@am__objects_1 = lib_a-strcmp.$(OBJEXT)
@HAVE_THUMB1_TRUE@@OPT_SIZE_FALSE@am__objects_1 =  \
@HAVE_THUMB1_TRUE@@OPT_SIZE_FALSE@	lib_a-strcmp.$(OBJEXT)
@OPT_SIZE_TRUE@am__objects_1 = lib_a-strcmp.$(OBJEXT)
================================

We can see that the value of am__objects_1 is always lib_a-strcmp.$(OBJEXT). It is totally out of our expectation. The reason is that if we firstly define "a=b", and then define "a=c". The final value of a is "b c" but not "c". So it is not overriding the previous value but just adding the value to the previous one.

I change the commands in Makefile.am to:
================================
if HAVE_THUMB1
if OPT_SIZE
STRCMP_SRC=strcmp.S
STRCMP_OBJ=$(lpfx)strcmp.o
else
STRCMP_SRC=
STRCMP_OBJ=
endif
else
STRCMP_SRC=strcmp.S
STRCMP_OBJ=$(lpfx)strcmp.o
endif
================================

And the generated commands in Makefile.in:
================================
@HAVE_THUMB1_FALSE@am__DEPENDENCIES_1 = $(lpfx)strcmp.o
@HAVE_THUMB1_TRUE@@OPT_SIZE_TRUE@am__DEPENDENCIES_1 = $(lpfx)strcmp.o
@HAVE_THUMB1_FALSE@am__objects_1 = lib_a-strcmp.$(OBJEXT)
@HAVE_THUMB1_TRUE@@OPT_SIZE_TRUE@am__objects_1 =  \
@HAVE_THUMB1_TRUE@@OPT_SIZE_TRUE@	lib_a-strcmp.$(OBJEXT)
================================

These generated commands are correct. Although they look a bit redundant.
Do you have any suggestion about this. 

Hale Wang.


> -----Original Message-----
> From: Hale Wang [mailto:Hale.Wang@arm.com]
> Sent: 2014年8月20日 17:51
> To: 'Jeff Johnston'; newlib@sourceware.org
> Subject: RE: Update newlib to support efficient string operation functions for
> Thumb.
> 
> 
> 
> > -----Original Message-----
> > From: newlib-owner@sourceware.org [mailto:newlib-
> > owner@sourceware.org] On Behalf Of Jeff Johnston
> > Sent: 2014年8月20日 1:24
> > To: newlib@sourceware.org
> > Subject: Re: Update newlib to support efficient string operation
> > functions for Thumb.
> >
> > ---- Original Message -----
> > > From: "Corinna Vinschen" <vinschen@redhat.com>
> > > To: newlib@sourceware.org
> > > Cc: "Jeff Johnston" <jjohnstn@redhat.com>
> > > Sent: Tuesday, August 19, 2014 7:01:45 AM
> > > Subject: Re: Update newlib to support efficient string operation
> > > functions
> > for Thumb.
> > >
> > > On Aug 19 11:01, Hale Wang wrote:
> > > > 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.
> > >
> > > Hmm, I'm wondering if that's really the right thing to do.  Jeff?
> > >
> >
> > Hale is correct in that an empty stub cannot be used because his
> > version will override the one in the shared portion of the library.
> >
> > There are a few ways of handling this.  One way is the way Hale did
> > it, but it's a bit of a hack.
> >
> > The cleanest way would be to use
> > configuration.  Since there are compiler macros that must be tested,
> > the configure would need to do a compile test which would look for the
> > flags in question.
> >
> > An example of this can be found in the newlib/configure.in for testing
> > for long double support.  So, using that as a base, something like the
> > following would go in the arm configure.in file:
> >
> > AC_CACHE_CHECK(whether we are using thumb1,
> >                acnewlib_cv_thumb1_processor, [dnl cat > conftest.c
> > <<EOF
> >
> > # if defined (__thumb__) && !defined (__thumb2__)
> >   #define _THUMB1
> >  #else
> >   #error "not thumb1"
> > #endif
> > int main() {
> >   return 0;
> > }
> > EOF
> > if AC_TRY_COMMAND([${CC} $CFLAGS $CPPFLAGS -c -o conftest.o
> conftest.c
> >                                                         1>&AS_MESSAGE_LOG_FD]) then
> >   acnewlib_cv_thumb1_processor=yes;
> > else
> >   acnewlib_cv_thumb1_processor=no;
> > fi
> > rm -f conftest*])
> > AM_CONDITIONAL(HAVE_THUMB1, test
> x"$acnewlib_cv_thumb1_processor"
> > = x"yes")
> >
> > You now have a way of checking for thumb1 in arm's Makefile.am.  For
> > the opt space option, you can either just use the target_optspace
> > variable set in
> > acinclude.m4 and add an AM_CONDITIONAL to configure.in in arm:
> >
> > AM_CONDITIONAL(OPT_SPACE, test x"target_optspace" = x"yes")
> >
> > or if the optimization isn't always specified by
> > --enable-target-optspace, you can add another test to configure.in for
> > the macros PREFER_SIZE_OVER_SPEED and __OPTIMIZE_SIZE__ macros.
> >
> > Now, inside the arm Makefile.am you add:
> >
> > STRCMP_SRC=strcmp.S
> > STRCMP_OBJ=$(lpfx)strcmp.o
> >
> > if HAVE_THUMB1
> >   if OPT_SPACE
> >   else
> >     STRCMP_SRC=
> >     STRCMP_OBJ=
> >   endif
> > endif
> >
> > You then replace strmp.S in the lib_a_SOURCES line with $(STRCMP_SRC)
> > and add
> > lib_a_LIBADD=$(STRCMP_OBJ)
> > lib_a_DEPENDENCIES=$(STRCMP_OBJ)
> >
> > Now, strcmp.o is optionally removed if the conditions match your
> > reason to use string/strcmp.c.
> >
> > I think that arm may in the future want to have separate .S files for
> > various models to make things easier to read/maintain.  The
> > configuration method above would work for that so once you add the
> > code above, it makes it easy for someone later to copy and use for that
> purpose.
> >
> 
> This is an useful and clean solution to decide which object file need to be
> generated. And I am sure this solution works well to fix this problem.
> 
> I will try this solution locally not only just for strcmp(), strlen(), but also all the
> other functions in libc/machine/arm/ which may have the same problem.
> 
> Thanks for your help.
> 
> Hale Wang
> 
> > -- Jeff J.
> >
> >
> > >
> > > Corinna
> > >
> > > --
> > > Corinna Vinschen
> > > Cygwin Maintainer
> > > Red Hat
> > >