This is the mail archive of the gcc-help@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]

Re: Optimizing constructors/destructors for embedded systems


KÃvesdi GyÃrgy wrote:
>> 2) If they are not virtual, unused variants of the destructor should go
>> away by means of function-level linking (on gcc by compiling with
>> -ffunction-sections and linking with --gc-sections).
> I tried it, but applying the option --gc-sections results in an empty 
> executable file. Am I missed something? Without it everyting works in the 
> known way.

You have to tell the linker explicitly to keep (at least) the entry
point of your program. With -ffunction-sections and --gc-sections, we
basically tell the linker to calculate the closure of reachable
(referenced) symbols and included only those into the output. However,
you have to give a starter set for this calculation by marking some
symbol (usually the CRT startup function) as to be included in every
case. Look for KEEP in the linker script language documentation. There
is also a linker switch for the same purpose.

> BTW I wanted to try what happens if those functions are virtual and the 
> mentioned options are used. I know that using virtual functions have its 
> cost, but I don't know its couple to the operator delete(). Of course I will 
> avoid using them as far as it is possible, but I want to know their behavior.

Virtual functions can't be removed by the linker, as they are referenced
by the virtual function table. This is one of their major disadvantages
with respect to embedded platforms.
As virtual functions are resolved at run-time, the linker just can not
decide at link-time if they are used or not. That's simply the magic
(and curse) of late binding. It hinders dead code elimination.

In theory, a C++ compiler could optimize away the "virtual keyword" for
functions for which he can prove that they are never invoked
polymorphically. However, this is very difficult, as it requires a
whole-program translation approach, which conflicts with the traditional
separation of compiler, linker, and make tool as well as the concept of
single translation units. I am not aware of any mature C++ compiler that
performs such optimizations.

Hence, if your destructors have to be virtual, you just have to accept
the fact that some variants of them are generated even though they are
never used. Neither the compiler nor the linker could know so. However,
by defining a dummy symbol for operator delete, you could at least
minimize the follow-up costs.


Daniel


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