This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: Update newlib to support efficient string operation functions for Thumb.
- From: "Hale Wang" <Hale dot Wang at arm dot com>
- To: "'Jeff Johnston'" <jjohnstn at redhat dot com>, <newlib at sourceware dot org>
- Date: Fri, 22 Aug 2014 10:50:02 +0800
- Subject: RE: Update newlib to support efficient string operation functions for Thumb.
- Authentication-results: sourceware.org; auth=none
- References: <000601cfb776$33efa100$9bcee300$ at arm dot com> <20140814082817 dot GB17310 at calimero dot vinschen dot de> <00dc01cfbb59$f0624810$d126d830$ at arm dot com> <20140819110145 dot GP2280 at calimero dot vinschen dot de> <1742674848 dot 32553795 dot 1408469066584 dot JavaMail dot zimbra at redhat dot com>
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
> > >