This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS, libsupc++ and -G 0


Richard Sandiford wrote:
Zack Weinberg <zack@codesourcery.com> writes:

Richard Sandiford <rsandifo@redhat.com> writes:

The only reliable way to get what you want is to either (a) add -G0
multilibs or (b) change the default -G setting.  Perhaps a configure
option would be useful here.  Maybe something like --with-sdata-limit,
to go alongside options like --with-arch and --with-tune?

Or perhaps an -m option to put stuff in .sdata as normal, but generate code as if nothing is in there?


Maybe (and I realise other ports do) but in some ways it gives the worst
of both worlds.  libsupc++ and libstdc++ will end up eating chunks of the
small data area without getting any real benefit from it.

A configure-time option is likely to be more convenient for folks who
use -G0 because you don't have to coerce every build system to add it
on the command line.  And it wouldn't penalise those who want to use
the usual -G8.

Unfortunately the decision to use or not use -G 0 isn't taken on a per-compiler basis usually, but a per-application one. A -G 0 multilib doesn't seem good either because someone may have an application that doesn't link with -G 8, but might with -G 4, and at least get some benefit from small data. Or arguably -G 2.


I think for what is in effect a system library, Zack's proposal seems least bad, even though it has drawbacks. And potentially no drawbacks if someone ever implements linker relaxation for MIPS.

Jifl


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