@@ -145,11 +145,14 @@ vxworks_override_options (void)
targetm.emutls.debug_form_tls_address = true;
}
- /* We can use .ctors/.dtors sections only in RTP mode. But, if the
- compiler was built with --enable-initfini-array, assume the
- toolchain implements the proper glue to make .init_array and
- .fini_array work. */
- targetm.have_ctors_dtors = TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT;
+ /* Arrange to use .ctors/.dtors sections if the target VxWorks configuration
+ and mode supports it, or the init/fini_array sections if we were
+ configured with --enable-initfini-array explicitly. In the latter case,
+ the toolchain user is expected to provide whatever linker level glue is
+ required to get things to operate properly. */
+
+ targetm.have_ctors_dtors =
+ TARGET_VXWORKS_HAVE_CTORS_DTORS || HAVE_INITFINI_ARRAY_SUPPORT;
/* PIC is only supported for RTPs. */
if (flag_pic && !TARGET_VXWORKS_RTP)
@@ -142,13 +142,18 @@ along with GCC; see the file COPYING3. If not see
#define VXWORKS_OVERRIDE_OPTIONS vxworks_override_options ()
extern void vxworks_override_options (void);
-/* RTPs support prioritized constructors and destructors: the
- implementation relies on numbered .ctors* sections. If the compiler
- was built with --enable-initfini-array, we assume the user uses a
- linker script that sorts and merges the .init_array.* sections
- appropriately. */
+/* Whether the VxWorks variant and mode supports constructors/destructors
+ placed in .ctors/.dtors section or if we should generate proxy functions
+ for them, with special names which munch knows how to collect. On most
+ versions of VxWorks, only the RTP loader supports .ctors/.dtors sections,
+ not the kernel module loader. */
+#define TARGET_VXWORKS_HAVE_CTORS_DTORS TARGET_VXWORKS_RTP
+
+/* Support for prioritized ctors/dtors is in sync with the support for sections
+ on the VxWorks front, and is assumed to be provided by whatever linker level
+ glue is required if we were configured with --enable-initfini-array. */
#define SUPPORTS_INIT_PRIORITY \
- (TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT)
+ (TARGET_VXWORKS_HAVE_CTORS_DTORS || HAVE_INITFINI_ARRAY_SUPPORT)
#if !HAVE_INITFINI_ARRAY_SUPPORT
/* VxWorks requires special handling of constructors and destructors.
Hello, The support for constructors/destructors on VxWorks evolves and the current distinction between RTP vs kernel mode isn't precise enough any more. The attached patch, originally contributed by Jerome Lambourg for gcc-7, introduces a TARGET_VXWORKS_HAVE_CTORS_DTORS internal macro which allows target ports to state their own setting, propagated to both targetm.have_ctors_dtors and SUPPORTS_INIT_PRIORITY in a synchronized fashion. This helps fix problems we observed on the aarch64 port we're working on without introducing any visible regression in our nightly testing of other ports based on gcc-7. I adapted the patch to mainline, verified that I could build a powerpc-wrs-vxworks compiler and that a constructor attribute still operates as expected for this target, producing a .ctors entry with -mrtp and a specially named (GLOBAL_I) wrapper function otherwise. Olivier 2018-11-16 Jerome Lambourg <lambourg@adacore.com> Olivier Hainque <hainque@adacore.com> * config/vxworks.h (TARGET_VXWORKS_HAVE_CTORS_DTORS): New macro. Default to TARGET_VXWORKS_RTP. (SUPPORTS_INIT_PRIORITY): Use TARGET_VXWORKS_HAVE_CTORS_DTORS instead of TARGET_VXWORKS_RTP. * config/vxworksae.h: Also define TARGET_VXWORKS_HAVE_CTORS_DTORS. * config/vxworks.c: Use TARGET_VXWORKS_HAVE_CTORS_DTORS instead of TARGET_VXWORKS_RTP to set targetm.have_ctors_dtors.