public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <200101161619.f0GGJZq20234@sheesh.cambridge.redhat.com> (raw)
In-Reply-To: <200101161536.PAA08774@colinf.pipinghotnetworks.com>

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

      parent reply	other threads:[~2001-01-16  8:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-16  5:51 Colin Ford
2001-01-16  6:36 ` Bart Veer
2001-01-16  7:38   ` Colin Ford
2001-01-16  7:46     ` Gary Thomas
2001-01-16  9:52       ` Jonathan Larmour
2001-01-17  5:33         ` Colin Spier
2001-01-16  8:19     ` Bart Veer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200101161619.f0GGJZq20234@sheesh.cambridge.redhat.com \
    --to=bartv@redhat.com \
    --cc=colin.ford@pipinghotnetworks.com \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).