[ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Christopher Cordahi]

Hi group,

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.

$ arm-elf-size.exe heap_with_delete.elf
   text    data     bss     dec     hex filename
  58320    1968   27732   88020   157d4 heap_with_delete.elf
$ arm-elf-size.exe heap_no_delete.elf
   text    data     bss     dec     hex filename
  58304    1968   27732   88004   157c4 heap_no_delete.elf
$ arm-elf-size.exe no_heap_with_delete.elf
   text    data     bss     dec     hex filename
  48640    1528   25556   75724   127cc no_heap_with_delete.elf
$ arm-elf-size.exe no_heap_no_delete.elf
   text    data     bss     dec     hex filename
  48640    1528   25556   75724   127cc no_heap_no_delete.elf

This option with its default setting saves a few bytes of memory
at the expense of the C++ delete operator not working.

If this option is to be preserved, I would think that empty
delete functions should be a user optimization not
an unexpected default.

Also the description of the option is much too complicated
and I don't even think it's correct, since virtual destructors
don't seem to have any influence on the code linked in.

# Provide empty C++ delete functions
# To deal with virtual destructors, where the correct delete()
# function must be called for the derived class in question, the
# underlying delete is called when needed, from destructors.  This
# is regardless of whether the destructor is called by delete itself.
# So there is a reference to delete() from all destructors.  The
# default builtin delete() attempts to call free() if there is
# one defined.  So, if you have destructors, and you have free(),
# as in malloc() and free(), any destructor counts as a reference
# to free().  So the dynamic memory allocation code is linked
# in regardless of whether it gets explicitly called. This
# increases code and data size needlessly.
# To defeat this undesirable behaviour, we define empty versions
# of delete and delete.  But doing this prevents proper use
# of dynamic memory in C++ programs via C++'s new and delete
# operators.
# Therefore, this option is provided
# for explicitly disabling the provision of these empty functions,
# so that new and delete can be used, if that is what is required.
#
cdl_option CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS {
    # Flavor: bool
    # No user value, uncomment the following line to provide one.
    # user_value 1
    # value_source default
    # Default value: 1
};


-- 
Chris

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

Re: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Andrew Lunn]

On Tue, Feb 06, 2007 at 01:29:12PM -0500, Christopher Cordahi wrote:
> Hi group,
> 
> 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.

> 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.

> 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. 

              Andrew

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

Re: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Christopher Cordahi]

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.

> > 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.

-- 
Chris

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

Re: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Andrew Lunn]

On Tue, Feb 06, 2007 at 04:24:39PM -0500, 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.

You are incorrect. Look at the documentation for -ffunction-sections.
This is the default for eCos since we want to throw away all the
unused junk.

> 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.

The problem with C++ is that it does all sorts of things behind your
back which you have no control over. This is one example. It pulls in
delete aka free when its not needed for most people. In most embedded
systems you allocate your classes once at startup time and they then
live until crash/power off. The delete is never called. Or you use
placement new and again you never need delete.

> 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.

I'm not a C++ programmer, but from what you describe, since it was on
the stack, you actually don't need delete and it is just bloat for
you.

        Andrew

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

Re: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Christopher Cordahi]

On 06/02/07, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Feb 06, 2007 at 04:24:39PM -0500, 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.
>
> You are incorrect. Look at the documentation for -ffunction-sections.
> This is the default for eCos since we want to throw away all the
> unused junk.

Thanks, I never noticed that, I'll try and determine why free is still
linked in.
My ecos/include/pkgconf/ecos.mak file seems to contain the necessary
options
ECOS_GLOBAL_CFLAGS = -ffunction-sections -fdata-sections
ECOS_GLOBAL_LDFLAGS = -Wl,--gc-sections

Application level functions which are not called seem to be omitted.
Could there be a problem with how the modules in ecos library
are compiled?

> > 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.
>
> The problem with C++ is that it does all sorts of things behind your
> back which you have no control over. This is one example. It pulls in
> delete aka free when its not needed for most people. In most embedded
> systems you allocate your classes once at startup time and they then
> live until crash/power off. The delete is never called. Or you use
> placement new and again you never need delete.

I guess I disagree over the idea that there is no control over the
inclusion of delete.  From my tests if it is never called, it's never
included.  Could this be a holdover from an obsolete gcc?
If it is, I believe users would prefer that it behave as expected rather
than optimizing for a situation that doesn't exist.

> > 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.
>
> I'm not a C++ programmer, but from what you describe, since it was on
> the stack, you actually don't need delete and it is just bloat for
> you.

It was just a test of the problem mentioned in the description of the
option.  You're right it was just bloat, and since delete was never called,
it was never linked in and neither was free without the need for the option.

-- 
Chris

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

Re: [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

[ECOS] Re: Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Sergei Organov]

"Christopher Cordahi" <christopher.cordahi@gmail.com> writes:
> On 06/02/07, Andrew Lunn <andrew@lunn.ch> wrote:

[...]

> 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.

Depending on GCC version, it could be not enough to just have one virtual
destructor, -- you may need to have inheritance to see the problem, e.g.:

struct A {
  virtual ~A();
};

struct B: public A {
  virtual ~B();
};

A::~A() {}
B::~B() {}

When I compile this file to assembly, I see a call to __builtin_delete
using old versions of GCC (2.95.x), and calls to an external symbol
_ZdlPv using newer version of GCC :(

-- Sergei Organov.


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

Re: [ECOS] Re: Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[osv]

"Christopher Cordahi" <christopher.cordahi@gmail.com> writes:
> On 07/02/07, Sergei Organov <osv@javad.com> wrote:
>> "Christopher Cordahi" <christopher.cordahi@gmail.com> writes:
>> > On 06/02/07, Andrew Lunn <andrew@lunn.ch> wrote:
>>
>> [...]
>>
>> > 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.
>>
>> Depending on GCC version, it could be not enough to just have one virtual
>> destructor, -- you may need to have inheritance to see the problem, e.g.:
>>
>> struct A {
>>   virtual ~A();
>> };
>>
>> struct B: public A {
>>   virtual ~B();
>> };
>>
>> A::~A() {}
>> B::~B() {}
>
> That's basically what I had, I included printfs in the constructor and
> destructor to watch what was being constructed and destructed in
> my tests.
>
>> When I compile this file to assembly, I see a call to __builtin_delete
>> using old versions of GCC (2.95.x), and calls to an external symbol
>> _ZdlPv using newer version of GCC :(
>
> I don't understand your use of :(.
> Are you confirming that the option doesn't work as expected?

It meant "unfortunately", as I thought that existence of those calls
actually results in fetching unnecessary routines from libraries, thus
justifying the existence of the eCos option.

>From what I see there are 3 destructors for the same object,
> and different ones are called for different situations and if the
> destructor is never called via the delete operator, the one with a
> call to delete is not linked in.

Well, with the 2.95 GCC for ARM, when I compile the code:

class A
{
public:
  virtual ~A();
  int a;
};

class B: public A
{
public:
  virtual ~B();
  int b;
};

A::~A() {}
B::~B() {}

int foo()
{
  B b;
  return b.b;
}

I get the assembly where foo() calls _._1B that in turn calls _._1A that
in turn calls __builtin_delete.

With newer GCC it seems that the generated code indeed doesn't call the
destructor that contains reference to external _ZdlPv, and then your
observations are right.

I have no idea when exactly GCC changed its behavior in this field, but
it seems that those eCos option is only required for older GCC.

For reference, here is the assembly got with GCC 2.95.2 that does
reference __builtin_delete:

.gcc2_compiled.:
.text
	.align	2
	.global	_._1A
	.type	 _._1A,function
_._1A:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, current_function_anonymous_args = 0
	mov	ip, sp
	stmfd	sp!, {fp, ip, lr, pc}
	sub	fp, ip, #4
	ldr	r3, .L6
	tst	r1, #1
	str	r3, [r0, #4]
	ldmeqea	fp, {fp, sp, pc}
	bl	__builtin_delete
	ldmea	fp, {fp, sp, pc}
.L7:
	.align	2
.L6:
	.word	_vt.1A
.Lfe1:
	.size	 _._1A,.Lfe1-_._1A
	.align	2
	.global	_._1B
	.type	 _._1B,function
_._1B:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, current_function_anonymous_args = 0
	mov	ip, sp
	stmfd	sp!, {fp, ip, lr, pc}
	ldr	r3, .L10
	sub	fp, ip, #4
	str	r3, [r0, #4]
	bl	_._1A
	ldmea	fp, {fp, sp, pc}
.L11:
	.align	2
.L10:
	.word	_vt.1B
.Lfe2:
	.size	 _._1B,.Lfe2-_._1B
	.align	2
	.global	foo__Fv
	.type	 foo__Fv,function
foo__Fv:
	@ args = 0, pretend = 0, frame = 12
	@ frame_needed = 1, current_function_anonymous_args = 0
	mov	ip, sp
	stmfd	sp!, {r4, fp, ip, lr, pc}
	sub	fp, ip, #4
	sub	r3, fp, #28
	mov	r0, r3
	ldr	r2, .L24
	sub	sp, sp, #12
	str	r2, [r3, #4]
	mov	r1, #2
	ldr	r4, [fp, #-20]
	bl	_._1B
	mov	r0, r4
	b	.L23
.L25:
	.align	2
.L24:
	.word	_vt.1B
.L23:
	ldmea	fp, {r4, fp, sp, pc}
.Lfe3:
	.size	 foo__Fv,.Lfe3-foo__Fv
	.weak	_vt.1B
	.section .gnu.linkonce.d._vt.1B,"aw"
	.align	2
	.type	 _vt.1B,object
	.size	 _vt.1B,24
_vt.1B:
	.short	0
	.short	0
	.word	0
	.short	0
	.short	0
	.word	_._1B
	.space	8
	.weak	_vt.1A
	.section .gnu.linkonce.d._vt.1A,"aw"
	.align	2
	.type	 _vt.1A,object
	.size	 _vt.1A,24
_vt.1A:
	.short	0
	.short	0
	.word	0
	.short	0
	.short	0
	.word	_._1A
	.space	8


-- Sergei.

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

Re: [ECOS] Re: Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS

[Christopher Cordahi]

On 07/02/07, osv@javad.com <osv@javad.com> wrote:
>
> [snip]
>
> With newer GCC it seems that the generated code indeed doesn't call the
> destructor that contains reference to external _ZdlPv, and then your
> observations are right.
>
> I have no idea when exactly GCC changed its behavior in this field, but
> it seems that those eCos option is only required for older GCC.

Apparently somewhere between GCC 2.95 and 3.2.1.

Since according to http://ecos.sourceware.org/build-toolchain.html
"It is recommended that eCos is built with GCC 3.2.1 at present.",
I would recommend that the default configuration take that into
consideration and by default have the destructors free the memory
as requested by the code.  The optimization to save some codespace
when used with a very old compiler should be something a user
explicitly requests.

> For reference, here is the assembly got with GCC 2.95.2 that does
> reference __builtin_delete:
>
> [snip]

-- 
Chris

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