RE: [ECOS] waitpid and alarm?

["Colin Spier" <Colin.Spier@pipinghotnetworks.com>]

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
>