RFA: Remove ARM syscall support from newlib

[Richard Earnshaw]

On 02/08/11 15:51, Nick Clifton wrote:
> 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.
> 

     4. Set up a transition plan...

1) Add a dummy linker script in the newlib equivalent to the libgloss
version that newlib supports today (essentially rdimon).

2) Make the tools use that dummy script

3) Transition tools and users away from using the newlib-only version

4) Eventually retire the libgloss-free version of newlib.

Takes a bit longer, but I think gives the cleanest solution to this overall.


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