Bug#588391: gcc-4.4: please automatically use -ffunction-sections
> On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose <doko@debian.org> wrote:
> > On 06.08.2010 00:58, brian m. carlson wrote:
> >>
> >> On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote:
> >>>
> >>> On 08.07.2010 01:42, brian m. carlson wrote:
> >>>>
> >>>> Package: gcc-4.4
> >>>> Version: 4.4.4-6
> >>>> Severity: wishlist
> >>>>
> >>>> Because the ELF ABI for hppa requires relative jumps which are limited
> >>>> to 17 bits[0], programs frequently require the use of
> >>>> -ffunction-sections. =A0It would be preferable if (on hppa or otherwis=
> e)
> >>>> -ffunction-sections were implied by -fPIC when otherwise gcc would
> >>>> generate text sections that are too large. =A0After all, there's reall=
> y no
> >>>> reason to generate .o files that are, for all practical purposes,
> >>>> useless. =A0It would also make numerous package maintainers and hppa
> >>>> porters very happy, I suspect.
> >>>>
> >>>> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D558999#15
> >>>
> >>> as this specific example shows, -ffunction-sections isn't enough,
> >>> but -mlong-calls is needed.
> >>
> >> In that particular instance -mlong-calls is needed, but in the general
> >> case it appears not to be, judging from the numerous cases where only
> >> -ffunction-sections (and not -mlong-calls) is in use already in the
> >> archive. =A0For example, #160538.
> >>
> >> My wishlist request still stands.
> >
> > waiting for feedback form the HPPA porters.
>
> To make this automatic would require a lot more intelligence in the
> linker. My suggestion is to change the specs such that -fPIC implies
> -ffunction-sections.
The linker suggestion to use -ffunction-sections is somewhat misleading.
I suspect that problems arise in C++ and computer generated code due to
massive inlining resulting in very large objects and overflow of the stub
table. If the stub table overflows, -ffunction-sections isn't going to
help. There are ways to limit inlining.
GCC automatically switches to long calls when the distance to the
stub table gets too large. However, this fails if objects are combined
and relinked.
The 17-bit offset is a PA 1.X limitation and has nothing to do with
ELF. The 17-bit branches provide the shortest calling sequence for
functions in most circumstances. With PA 2.0, the offset for calls
changes to 21 bits. However, there still could be problems with
thunks since they use an unconditional branch with a 17-bit offset.
The whole approach stems from the hpux runtime design. Probably, it
would have been better under linux to allocate enough space for a long
call, and have the linker optimize the type of call.
I don't think -fPIC and -ffunction-sections have any relationship.
Possibly, -function-sections should be the default. Another possibility
is to start a new unnamed .text section at the beginning of every
function when -ffunction-sections isn't specified. Effectively, this
is what happens under hpux. A new subspace is started at the beginning
of every function. It does mean that it is not possible to switch sections
mid function. So, hot and cold sections are not possible. However,
we don't support hot and cold sections because it messes with branch
distance calculations.
The whole issue is quite complicated and I don't think any simple
change will resolve all the problems.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Reply to: