public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [patch] cleanup handling of libgcc and libc_internal for VxWorks
@ 2018-09-20 14:55 Olivier Hainque
  0 siblings, 0 replies; only message in thread
From: Olivier Hainque @ 2018-09-20 14:55 UTC (permalink / raw)
  To: GCC Patches

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

Hello,

For static RTPs, libc_internal is included
in link closures through LIB_SPEC and LIBGCC_SPEC, which makes
it hard to conditionally remove with command line options
such as -nolibc.
    
This change arranges to have libc_internal dragged in from
LIB_SPEC only and reworks the ordering of libs that
participate in LIB_SPEC to match a rationale that the head
comment can state.

We have been using this for a while in our gcc-7 based toolchains
on several targets.

I checked on a gcc-8 based source tree that I can still
build functional compilers passing Ada ACATS for VxWorks
6.9 and 7.0.

Bootstrapped and reg tested on mainline for x86_64-linux.

With Kind Regards,

Olivier

2018-09-20  Olivier Hainque  <hainque@adacore.com>

	* config/vxworks.h (VXWORKS_LIBGCC_SPEC): Remove -lc_internal.
	Merge block comment with the one ahead of VXWORKS_LIBS_RTP. Then:
	(VXWORKS_LIBS_RTP): Minor reordering.


[-- Attachment #2: 0006-Cleanup-handling-of-libgcc-and-libc_internal-for-VxW.patch --]
[-- Type: application/octet-stream, Size: 1875 bytes --]

--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -65,14 +65,17 @@ along with GCC; see the file COPYING3.  If not see
 
 #endif
 
-/* The references to __init and __fini will be satisfied by
-   libc_internal.a, and some versions of VxWorks rely on explicit
-   extra libraries for system calls.  */
+/* For VxWorks static rtps, the system provides libc_internal.a, a superset of
+   libgcc.a that we need to use e.g. to satisfy references to __init and
+   __fini.  We still want our libgcc to prevail for symbols it would provide
+   (e.g. register save entry points), so re-place it here between libraries
+   that might reference it and libc_internal.  Also, some versions of VxWorks
+   rely on explicit extra libraries for system calls.  */
 
 #define VXWORKS_SYSCALL_LIBS_RTP
 
 #define VXWORKS_LIBS_RTP \
-  VXWORKS_SYSCALL_LIBS_RTP " -lc -lgcc -lc_internal -lnet -ldsi"
+  VXWORKS_SYSCALL_LIBS_RTP " -lnet -ldsi -lc -lgcc -lc_internal"
 
 /* On Vx6 and previous, the libraries to pick up depends on the architecture,
    so cannot be defined for all archs at once.  On Vx7, a VSB is always needed
@@ -118,13 +121,8 @@ along with GCC; see the file COPYING3.  If not see
  %{mrtp:%{!shared:%{!non-static:-static}		\
  		  %{non-static:--force-dynamic --export-dynamic}}}"
 
-/* For VxWorks static rtps, the system provides libc_internal.a, a superset
-   of libgcc.a that we want to use.  Make sure not to dynamically export any
-   of its symbols, though, and always look for libgcc.a first so that we get
-   the latest versions of the GNU intrinsics during our builds.  */
 #undef VXWORKS_LIBGCC_SPEC
-#define VXWORKS_LIBGCC_SPEC \
-  "-lgcc %{mrtp:%{!shared:--exclude-libs=libc_internal,libgcc -lc_internal}}"
+#define VXWORKS_LIBGCC_SPEC "-lgcc"
 
 #undef VXWORKS_STARTFILE_SPEC
 #define	VXWORKS_STARTFILE_SPEC "%{mrtp:%{!shared:-l:crt0.o}}"
-- 
1.7.10.4


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-09-20 14:49 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-20 14:55 [patch] cleanup handling of libgcc and libc_internal for VxWorks Olivier Hainque

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).