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
next prev parent 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).