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: RFA: Remove ARM syscall support from newlib


Hi Richard,

Won't this require all users to now use a link script in order to build
their binaries.  If so, then I think this will break testing of GCC.

You're right. :-(


*sigh*, so as I see there are three ways that we can proceed:

  1. Remove the ARM syscall and crt0.o from newlib and update
     gcc and dejagnu to cope with this.

     Undoubtedly lots of people will complain when they run
     into this.

  2. Keep things the way that they.  Try to keep the libgloss
     and newlib versions of crt0.o and the syscall functions
     synchronized.

This is error prone, but matches current practice.

3. Use the patch below.

     Now before anyone complains, I will admit that this is
     a horrible hack, but it does work, and it does mean
     that there would only be one copy of crt0.o and the
     syscall functions.

The patch relies upon the fact that the linker will accept linker script fragments as input files. So the normal crt0.o (in libgloss) is replaced by a fragment that loads the real crt0.o and the syscall functions (from libgloss, not newlib). There are two problems with this approach:

  1. The syscall functions are loaded *before* the rest of
     the objects on the linker command line, so they cannot
     be in a library.

     I solved this problem by compiling the syscall functions
     with -ffunction-sections specified.  So that if the final
     executable is linked with -gc-sections then any unused
     syscalls will be discarded.

  2. For some reason that I cannot work out, when compiling
     with -flto two copies of crt0.o are linked in.  Why this
     does not cause errors with normal crt0.o files I do not
     know, but the solution I have used here is to make the
     syscall functions weak.  That way duplicates do not
     matter, and if the user ever wants to provide their
     own syscall functions they can do so.


Tested by building an arm-eabi toolchain and then running the gcc testsuite.


So - what do other people think ?

Cheers
  Nick

newlib/ChangeLog
2011-08-02  Nick Clifton  <nickc@redhat.com>

	* configure.host (arm-*-*): Set have_crt0 to "no".
	Add note about ARM syscall support.
	* libc/sys/arm/Makefile.am: Remove syscall functions.
	* libc/sys/arm/configure.in (AC_CONFIG_SRCDIR): Use aeabi_atext.c.
	* libc/sys/arm/Makefile.in: Regenerate.
	* libc/sys/arm/aclocal.m4: Regenerate.
	* libc/sys/arm/configure: Regenerate.
	* libc/sys/arm/crt0.S: Delete.
 	* libc/sys/arm/libcfunc.c: Delete.
	* libc/sys/arm/swi.h: Delete.
	* libc/sys/arm/syscalls.c: Delete.
	* libc/sys/arm/trap.S: Delete.
	* libc/sys/arm/README-syscalls: New file.

libgloss/ChangeLog
2011-08-02  Nick Clifton  <nickc@redhat.com>

	* arm/Makefile.in (CRT0): Always define.
	(NEWLIB_CRT0): Define.
	(NEWLIB_OBJS): Define.
	(CRT0_INSTALL): Always define.
	(all): Add NEWLIB_CRT0 and NEWLIB_OBJS.
	crt0.o: Build from crt0.in.
	(install-newlib): New target.
	* arm/configure.in: Remove check of
	disable-newlib-supplied-syscalls.
	* arm/configure: Regenerate.
	* arm/crt0.S: Make function symbols weak.
	* arm/syscalls.c: Make functions weak.
	(_kill): Import from newlib.
	(_exit): Import from newlib.
	* arm/crt0.in: New file.


Attachment: newlib.arm.patch.2
Description: Unix manual page


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