This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos 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: Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS


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


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