This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Does -gc-section (garbage collection) works only with static linking ?
Hi agian Nick,
> Now of course you could argue that this logic applies to dynamically
> linked code as well. If the linker sees that there are no references
> to the symbol "myfxptr" and that this is the only symbol in a particular
> input section then that input section cannot be used by any code. So it
> could throw the section away. This is actually true in theory, but in
> practice there is a problem. All sections have a name. This name is
> globally visible, and therefore it can be seen by things outside of the
> dynamically linked code. So in theory something could want to use the
> contents of that section, accessing it via its section-name, even though
> there are no other references to any symbols inside that section. So
> the linker has to keep the section present in the dynamic
> executable/library.
So if I understand you right, my program compiled by GCC (or whatever in GNU
environment) contains a lot of entry points (one for each section) and any
person can build dynamic library that expects such entry points from my
program...
Nothing to say here... I just want to cry...
Finally when our discussion gets to its logic end I want to say the
following:
Without this kind of this optimization (thanks to you for it became
available now) you give one additional argument to those people who argue to
use C instead of C++. Let the C++ be ! :)
This can be treated horrible for some people, but I'm using C++ for embedded
programming in RTEMS environment. I've used static linking with
garbage-collection and saved yesterday about 15% of the size of my program.
Currently I'm going to rebuild RTEMS and STL with -ffunction-sections
expecting better results.
Sorry again for disturbing you Nick, but I suppose there are a lot of C++
programs now in Linux environment that could and must have smaller size.
Best regards,
Valery