[RFC] Removing __dso_handle definition for targets where DSOs are not used
Jozef Lawrynowicz
jozef.l@mittosystems.com
Wed Oct 30 19:52:00 GMT 2019
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-REMOVE_DSO_HANDLE.patch
Type: text/x-patch
Size: 1918 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20191030/c5aa27c8/attachment.bin>
More information about the Gcc
mailing list