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: "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.

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