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: Jeff Johnston <jjohnstn at redhat dot com>
- To: newlib at sourceware dot org
- Date: Tue, 19 Aug 2014 13:24:26 -0400 (EDT)
- 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>
---- 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
>