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 06:36:00 -0000	[thread overview]
Message-ID: <200101161436.f0GEa8Y18858@sheesh.cambridge.redhat.com> (raw)
In-Reply-To: <200101161350.NAA08376@colinf.pipinghotnetworks.com>

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

    Colin> Hello,
    Colin> I've seen this really strange problem. I'm compiling on
    Colin> Linux using a gcc mips cross compiler for my R3000 target.
    Colin> I've got the latest cvs version of eCos and the network and
    Colin> snmp modules.

    Colin> In the module
    Colin> net/snmp/agent/current/src/mibgroup/util_funcs.c the
    Colin> functions 'waitpid' and 'alarm' are used within the
    Colin> functions wait_on_exec and restart_hook. Now these two
    Colin> functions are not used but are defined at global scope.
    Colin> This means that they end up in the libtarget.a with the
    Colin> functions 'waitpid' and 'alarm' undefined.

    Colin> Thats all well and good and everything compiled. I then
    Colin> noticed that in my compile line I had -ffunction-sections
    Colin> and -fdata-sections so I took thoes out as they interfered
    Colin> with gdb and tried then to re-compile.

    Colin> Could I get it to compiler after that? not a chance! It
    Colin> seemed to think in the link that waitpid and alarm where
    Colin> undefined. Only putting -ffunction-section back in
    Colin> aliviated the problem?

    Colin> To get around the problem I #if them out and took out the
    Colin> -ffunction-section. That then allowed me to compile again.
    Colin> I think that maybe these functions need to be hashed out in
    Colin> the cvs code until waitpid and alarm can be supported.

    Colin> Many thanks for allowing me to rant,

The tools are behaving as expected. Without -ffunction-sections and
-fdata-sections, linking operates on a per-module basis. If any
functions in util_funcs.c are used then all functions in util_funcs.c
will end up in the final image, and hence all references must be
resolved. With -ffunction-sections linking operates at a finer grain
so e.g. wait_on_exec will only end up in the final image if there is
an explicit reference to it. The main goal is to keep down the size of
the final executable.

In general we do assume that people will make use of
-ffunction-sections and similar functionality. This allows us to
import external code like SNMP with minimal source changes, and when a
new version is released it can be imported more easily. I do not know
enough about the SNMP code to understand under what circumstances
if any wait_on_exec or restart_hook might be useful, but just
#ifdef'ing them out may have undesirable side effects and will
complicate future maintenance. Obviously waitpid() is not relevant to
eCos systems, but I believe that alarm() is already implemented in the
EL/IX compatability layer.

The real issue here is not the SNMP code but why you are unable to
debug reliably when using -ffunction-sections. In theory, as far as
debugging is concerned, there should be no real differences between
linking on a per-function or a per-module basis. In practice there may
well still be bugs in this area that need to be tracked down -
although that discussion might be more appropriate for the gdb mailing
list. 

Bart

  reply	other threads:[~2001-01-16  6:36 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 [this message]
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

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=200101161436.f0GEa8Y18858@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).