Re: -ffunction-sections and profiling
Greetings!
"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
> > > 2003-11-27 Randolph Chung <tausq@debian.org>
> > > John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
> > >
> > > * pa.c (hppa_profile_hook): Split gen_call_profiler into separate
> > > insns. Use the regular call expander for the call to the profiler.
> > >
> > > What version of gcc are you using?
> > >
> >
> > 3.3.3
>
> You need 3.4 for the above.
>
> > > There's always the potential for the stub table to get too large.
> > > You can play with the ld option --stub-group-size=N. Another possibility
> > > is to build PA 2.0 code.
> >
> > Thanks, will try the 2.0. Does this limit the binary in any practical
> > way?
>
> Won't work on PA 1.x gear (715's, 735's, etc). On the other hand,
> you gain the benefit of PA 2.0's 22-bit b,l instruction when using %r2
> as the link register. This provides more efficient calls in big apps.
>
OK, 2.0 works, trying different values of --stub-group-size moved the
linking problem elsewhere, but never seems to eliminate it. I would
have preferred the most portable binary. I still don't see why
-ffunction-sections makes profiling impossible. I suppose I could try
to disable the profiling images only on hppa, but of course dislike
one offs like these. Does Debian have a policy regarding binaries
that won't work across all machines of the arch -- i.e. do I have the
option of simply using -march=2.0 in a Debian package? I did
similarly for atlas some time ago, but there we have an elaborate
scheme to sequester subarch optimized code that won't run on all
machines of the arch.
Take care,
> Dave
> --
> J. David Anglin dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: