Re: mips: -G0 vs __dso_handle

[Richard Sandiford <richard at codesourcery dot com>]

Ian Lance Taylor <ian@airs.com> writes:
> DJ Delorie <dj@redhat.com> writes:
>> For mips-elf builds, crtbegin.o is built with -G 0 ("in case $gp isn't
>> used").  This makes __dso_handle be put in .data.  However, the
>> "prototype" created by cp/decl.c is "void *__dso_data" which causes
>> GPrel addressing if your application is built without -G 0 (i.e. the
>> default), which causes link problems.  This is causing numerous
>> testsuite failures like this example:
>> 
>> /dev/shm/ccvHNaHr.o: In function
>>    `__static_initialization_and_destruction_0(int, int)':
>>    omit-frame-pointer.C:(.text+0x58): relocation truncated to fit:
>>    R_MIPS_GPREL16 against `__dso_handle'
>> 
>> Ideas?
>
> Hack mips_in_small_data_p to check for this magic symbol and return
> false for it?

I think that's the wrong way around.  This looks to me like just another
case of the general rule that compiling x.c with -G0 and y.c with -GA (A>0)
is not safe if y.c refers to a normal B-byte (B<=A) variable in x.c.

Since the point of compiling libgcc and crt* with -G0 is precisely
to allow them to be linked with such -GA code, I think each variable
exported by them should be put into a small data section using
__attribute__((section...)).  This is what newlib does with its
_impure_ptr, for example.

[IMO, MIPS linker scripts should always include *(.sdata), even if every
object is compiled with -G0.  But even if a linker script doesn't include
.sdata, the linker orphan placement code should do something sensible.]

DJ: I was planning to look at this myself, but it sounds like your need
is more urgent than mine.  Are you going to be doing this very soon?

Richard