This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

[RFC] Removing __dso_handle definition for targets where DSOs are not used


For the MSP430 target, the concepts of a dynamic linker and shared objects are
not applicable. The target is generally resource constrained and if someone
wanted to use a dynamic linker (maybe as an academic curiosity) on one of the
more powerful devices I expect it would have to be written from scratch using
a very minimal custom implementation.

So I can't see any reason we would have to worry about loading/unloading DSOs
and needing to keep __dso_handle.
Newlib atexit related functions (including __cxa_atexit) maintain their own
dso_handle so the one in crtstuff.c is not needed there either.

This does require TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT to return true however,
since cp/decl.c will create a reference to __dso_handle in programs with
static destructors.

This may seem nitty but we can save ~100 bytes from a barebones empty main
program, by not requiring code to initialize data by default. It is feasible
that real applications can be written not requiring global data at all so this
isn't just an artificial code size saving.

When users of embedded targets approach GCC for the first time for target they
don't like to see unnecessary functions and data in the output executables,
particularly when they are concerned about code size.

Are there any factors I may have missed that means removing __dso_handle is
inappropriate? The attached patch has my proposal for what the mechanism to
remove __dso_handle might look like.

Thanks,
Jozef
>From bd9647e2e3794f33754575ac10b67c1a49729af7 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date: Wed, 30 Oct 2019 19:48:54 +0000
Subject: [PATCH] Implement REMOVE_DSO_HANDLE

---
 libgcc/config/msp430/t-msp430 | 1 +
 libgcc/crtstuff.c             | 8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libgcc/config/msp430/t-msp430 b/libgcc/config/msp430/t-msp430
index 17d85b6cb23..e896a5824f7 100644
--- a/libgcc/config/msp430/t-msp430
+++ b/libgcc/config/msp430/t-msp430
@@ -41,6 +41,7 @@ LIB2ADD = \
 	$(srcdir)/config/msp430/cmpd.c
 
 HOST_LIBGCC2_CFLAGS += -Os -ffunction-sections -fdata-sections -mhwmult=none
+CRTSTUFF_T_CFLAGS += -DREMOVE_DSO_HANDLE
 
 mpy.o: $(srcdir)/config/msp430/mpy.c
 	$(gcc_compile) $< -c
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index c93e1cbcaca..f18e1459c63 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -327,8 +327,13 @@ register_tm_clones (void)
    in every shared-object; in a main program its value is zero.  The
    object should in any case be protected.  This means the instance
    in one DSO or the main program is not used in another object.  The
-   dynamic linker takes care of this.  */
+   dynamic linker takes care of this.
+   For targets where DSOs are not applicable, REMOVE_DSO_HANDLE can be defined
+   to remove this declaration.  TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT must return
+   TRUE otherwise references to __dso_handle will be created when the middle-end
+   creates destructors for static objects.  */
 
+#ifndef REMOVE_DSO_HANDLE
 #ifdef TARGET_LIBGCC_SDATA_SECTION
 extern void *__dso_handle __attribute__ ((__section__ (TARGET_LIBGCC_SDATA_SECTION)));
 #endif
@@ -340,6 +345,7 @@ void *__dso_handle = &__dso_handle;
 #else
 void *__dso_handle = 0;
 #endif
+#endif
 
 /* The __cxa_finalize function may not be available so we use only a
    weak declaration.  */
-- 
2.17.1


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