[ECOS] waitpid and alarm?

[ECOS] waitpid and alarm?

[Colin Ford]

Hello,

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

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

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

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

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

Many thanks for allowing me to rant,
Col.

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

Re: [ECOS] waitpid and alarm?

[Bart Veer]

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

Re: [ECOS] waitpid and alarm?

[Colin Ford]

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 

Re: [ECOS] waitpid and alarm?

[Gary Thomas]

On 16-Jan-2001 Colin Ford wrote:
> 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?
> 

Hogwash?

Honestly, the text is probably quite old and certainly does not reflect
our experience in using these options with eCos.

Re: [ECOS] waitpid and alarm?

[Bart Veer]

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

Re: [ECOS] waitpid and alarm?

[Jonathan Larmour]

Gary Thomas wrote:
> 
> On 16-Jan-2001 Colin Ford wrote:
> > 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?
> >
> 
> Hogwash?
> 
> Honestly, the text is probably quite old and certainly does not reflect
> our experience in using these options with eCos.

Actually it is correct that the assembler/linker will create larger object
files, but this is purely the files themselves, not the size of your
program as loaded onto the target. To be honest, the size increase is
minimal anyway - I'm surprised it's worth mentioning.

We don't support gprof anyway, and we have had very very occasional
problems with debugging, when using stabs debugging formats.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

RE: [ECOS] waitpid and alarm?

[Colin Spier]

Well, we definitely have _significant_ problems debugging if we compile
with -ffunction-sections -fdata-sections and link with -Wl,--gc-sections.

If I build with the above directives, run the system and force a <CTRLC>
breakpoint, when I connect gdb it suggests that the code has stopped at
"0x80034d98 <_breakinst+4>:  move $sp,$s8" and only displays assembly code,
no source.  Also, 'info address main' says that 'Symbol "main" is a function
at address 0x0'.  I can set breakpoints in code, but they do not cause the
system to break...

However, if I build without the above directives, run the system and force a
<CTRLC> breakpoint, when I connect gdb it correctly shows the source code
for breakpoint() (i.e. the correct source code for where the system was
stopped), and 'info address main' says that the address is 0x80089274.  I
can set breakpoints in my code and they work!

Our tool chain is gcc 2.95.2, binutils 2.10.1, insight 5.0 (I've also tried
insight+dejagnu-weekly-20001124 and insight+dejagnu-weekly-20010116).

My conclusion, therefore, is that although the gcc info file may indeed be
hogwash, I'm inclined to believe the bit about having problems debugging ;)

--
Colin Spier
PipingHot Networks Ltd.
Office: +44 (0)1364 655500
DDI: +44 (0)1364 655521
Fax: +44 (0)1364 654625
mailto:colin.spier@pipinghotnetworks.com
http://www.pipinghotnetworks.com


> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 16 January 2001 17:52
> To: Gary Thomas
> Cc: Colin Ford; ecos-discuss@sources.redhat.com; bartv@redhat.com
> Subject: Re: [ECOS] waitpid and alarm?
>
>
> Gary Thomas wrote:
> >
> > On 16-Jan-2001 Colin Ford wrote:
> > > 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?
> > >
> >
> > Hogwash?
> >
> > Honestly, the text is probably quite old and certainly does not reflect
> > our experience in using these options with eCos.
>
> Actually it is correct that the assembler/linker will create larger object
> files, but this is purely the files themselves, not the size of your
> program as loaded onto the target. To be honest, the size increase is
> minimal anyway - I'm surprised it's worth mentioning.
>
> We don't support gprof anyway, and we have had very very occasional
> problems with debugging, when using stabs debugging formats.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine
>