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.



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