Jonathan Larmour <[EMAIL PROTECTED]> writes:
> On MIPS, libgcc is built with -G 0, which is used to ensure the contents
> don't assume they will be placed in the small data/bss section. Setting
> -G 0 is used to allow for the possibility of large applications, or
> those where even small data may be located more than 64k away from the
> gp pointer.
>
> However this is not done with libsupc++ or libstdc++. The result is that
> for some of my embedded applications, which require -G 0 themselves,
> "stderr" is far away from the gp pointer. This shouldn't matter except
> that vterminate.cc in libsupc++ was not compiled with -G 0 and thus is
> expecting to be able to use a 16-bit gp relative relocation, thus we get
> a link failure.
>
> Was this a conscious decision or an accident? Is the best route for me
> to just add -G 0 for all mips libstdc++/libsupc++, and submit that as a
> patch?
It sounds like you think -G0 should be a safe setting for everyone,
but it isn't really. You can't necessarily compile libraries with
-G0 and then link them against code compiled with -G8. libgcc is
an exception rather than the norm here.
libstdc++/libsupc++ have (or least potentially have) various global
variables that fit in the default -G8 limit. So suppose:
foo.cc in libstdc++ defines a variable "int x"
foo.h in libstdc++ declares a variable "extern int x"
inline function bar() in foo.h refers to "x"
user code calls bar()
The user code will inline bar() and refer directly to "x". If the
user code is compiled with -G8, it will expect "x" to be in the small
data section. It won't link properly if foo.cc was compiled with -G0.
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?
Richard
