This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi Hale,

Sorry, I did not try out the sequence.  You are correct that it is not
overriding with an empty setting.  You can remove the empty settings
in your else clause to reduce the lines.  the following example illustrates
the output.  This example assumes no setting of the values prior to the if
statement so the values won't be set when referred to and will default to empty.

if A
if B
X_SRC=x.c
X_OBJ=x.o
endif
else
X_SRC=x.c
X_OBJ=x.o
endif

@A_FALSE@X_SRC = x.c
@A_TRUE@@B_TRUE@X_SRC = x.c
@A_FALSE@X_OBJ = x.o
@A_TRUE@@B_TRUE@X_OBJ = x.o

-- Jeff J.

----- Original Message -----
From: "Hale Wang" <Hale.Wang@arm.com>
To: "Jeff Johnston" <jjohnstn@redhat.com>, newlib@sourceware.org
Sent: Thursday, August 21, 2014 10:50:02 PM
Subject: RE: Update newlib to support efficient string operation functions for Thumb.

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]