From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bart Veer <bartv@redhat.com>
To: colin.ford@pipinghotnetworks.com
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] waitpid and alarm?
Date: Tue, 16 Jan 2001 08:19:00 -0000
Message-id: <200101161619.f0GGJZq20234@sheesh.cambridge.redhat.com>
References: <200101161350.NAA08376@colinf.pipinghotnetworks.com> <200101161436.f0GEa8Y18858@sheesh.cambridge.redhat.com> <200101161536.PAA08774@colinf.pipinghotnetworks.com>
X-SW-Source: 2001-01/msg00265.html

>>>>> "Colin" == Colin Ford <colin.ford@pipinghotnetworks.com> writes:

    Colin> Thanks for the info Bart. The only thing is that I was put off somewhat
    Colin> by the gcc info on the two option -ffunction-sections and
    Colin> -fdata-sections,
    Colin> see the last paragraph below:

    Colin> @item -ffunction-sections
    Colin> @itemx -fdata-sections
    Colin> Place each function or data item into its own section in
    Colin> the output file if the target supports arbitrary sections.
    Colin> The name of the function or the name of the data item
    Colin> determines the section's name in the output file.

This paragraph is correct - bearing in mind that eCos depends on
toolchains which support arbitrary sections.

    Colin> Use these options on systems where the linker can perform
    Colin> optimizations to improve locality of reference in the
    Colin> instruction space. HPPA processors running HP-UX and Sparc
    Colin> processors running Solaris 2 have linkers with such
    Colin> optimizations. Other systems using the ELF object format as
    Colin> well as AIX may have these optimizations in the future.

Correct to some extent: -ffunction-sections does allow linkers to
group related functions together. However as far as we are concerned
the main use is with the linker's --gc-sections option. This paragraph
really refers to native development rather than embedded systems.

    Colin> Only use these options when there are significant benefits
    Colin> from doing so.

In the eCos context and when linking with --gc-sections, there are
significant benefits.

    Colin> When you specify these options, the assembler and linker
    Colin> will create larger object and executable files and will
    Colin> also be slower.

Only if the linker does not support --gc-sections.

    Colin> You will not be able to use @code{gprof} on all systems if
    Colin> you specify this option

This may be true, but currently we have no profiling support in eCos
so the issue has not been addressed.

    Colin> and you may have problems with debugging if you specify
    Colin> both this option and @samp{-g}.

This is software. There will be bugs. There may be bugs in the
compiler, linker, or gdb which only show up when using
-ffunction-sections. If there are such bugs then you may have
problems. So strictly speaking the statement is correct, but you can
say the same thing about all software.

There may well be problems when using debuggers other than gdb, for
example those debuggers might get confused by the large number of
sections. eCos users should not be affected.

Bart