Re: [ECOS] waitpid and alarm?

[Colin Ford <colin.ford@pipinghotnetworks.com>]

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

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

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

Only use these options when there are significant benefits from doing
so.  When you specify these options, the assembler and linker will
create larger object and executable files and will also be slower.
You will not be able to use @code{gprof} on all systems if you
specify this option and you may have problems with debugging if
you specify both this option and @samp{-g}.


Nice to know what you think of this?

Cheers,
Col

On 16 Jan 2001 14:36:08 +0000, Bart Veer wrote:
> >>>>> "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



-- 
===========================================
Colin Ford               PipingHot Networks
Software Engineer        +44 (0)1364 655510