[ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Gary Thomas]

Christopher Cordahi wrote:
> On 06/02/07, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Tue, Feb 06, 2007 at 01:29:12PM -0500, Christopher Cordahi wrote:
>> > I'm wondering about the actual usefulness of the
>> > CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS cdl option.
>> >
>> > If you use new which calls malloc, then you
>> > also have free linked in even if you never call it.
>>
>> That should be wrong. If you don't use something, the linker does not
>> include it. If you are seeing free included but not used find out why?
>> Get a linker cross reference and find out where it is being referenced
>> from. If you really find it is included but without a reference your
>> linker might be broken and producing bloated binaries.
> 
> I'm sorry if I'm incorrect, but from my understanding of the linker,
> it includes entire modules not functions.  Since malloc and free are
> in the same module, if new is used, both are automatically linked in.
> Am I incorrect?  Is there an option for the linker to link at the
> function/variable level?  I would greatly appreciate it.

A special function we had designed into GCC/LD just for this:
   -ffunction-sections -fdata-sections
these options tell GCC to split functions and data items into their own
ELF sections which the linker can then toss if they aren't referenced.

> 
>> > This option with its default setting saves a few bytes of memory
>> > at the expense of the C++ delete operator not working.
>>
>> Generally, if somebody is wanting to write small code, they use C and
>> avoid C++. So to me, this is the right way around. I'm typically using
>> a system with 64Kbytes of RAM and 256Kbytes of FLASH. Every byte
>> counts and i avoid C++ like the plague.
> 
> I agree 100%.
> If you don't want the overhead of C++, don't use it, but if you do
> use delete you would expect it to work properly.
> 
> To quote you "If you don't use something, the linker does not
> include it".  If you don't call delete, delete won't be linked in and
> hence free won't be linked in without any need for the option.
> 
>> > If this option is to be preserved, I would think that empty
>> > delete functions should be a user optimization not
>> > an unexpected default.
>>
>> You are taking the wrong tone here. "is to be preserved" makes it
>> sound like you have already decided to take it out and are letting
>> people argue it should be kept. In fact it is the other way
>> around. You need to convince us that the default value should be
>> changed and that the bloat added by changing the default really is
>> insignificant to all users.
> 
> Sorry if I sound presumptive, but I'm trying to get the reasoning
> for the option since it doesn't seem to work according to its
> confusing description and purpose.
> 
> I created and destroyed a C++ object with a virtual destructor that
> was on the stack and the the free function wasn't included in the
> object code since there wasn't any dynamic memory.
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss