This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]