RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

["Maciej W. Rozycki" <macro@linux-mips.org>]

On Fri, 17 Apr 2015, Petar Jovanovic wrote:

> This issue will not trigger a linker error (I believe it treats the
> symbol referred by the relocation as a local symbol). This is a follow
> up to GLIBC BZ #17601, the problem is seen only at runtime. So, I think
> this brings back the need to run the test. I can look into separating
> sections with -Wl,-T.. (that may also require extending
> mips_option_groups in mips/mips.exp), if running executable is OK.

 If the assembler or the linker knowingly (or under conditions where it 
can be determined) creates a broken executable, then it is a separate bug 
that needs to be filed against binutils.  Due to the unusual constraints 
of absolute MIPS jump instructions any associated symbol references have 
to result in external relocations, to be resolved in the final static link 
only.  If this is not the case or such a relocation resolves successfully 
despite a range overflow, then this has to be fixed in binutils.  Can you 
double-check if this is the case?

 I see this in a dump from crtbegin.o:

Disassembly of section .init:

00000000 <.init>:
   0:	04110001 	bal	8 <.init+0x8>
   4:	00000000 	nop
   8:	0c00004b 	jal	12c <frame_dummy>
			8: R_MIPS_26	.text
   c:	00000000 	nop

-- if `.text+0x12c' is out of range for JAL (R_MIPS_26) from `.init+0xc', 
that is the 4 most significant bits of both final addresses are not the 
same (the range calculation for this instruction/relocation is relative to 
the delay slot), then the static link is supposed to fail.  I think this 
can be easily verified and if needed, converted to an LD test case.

 As to a GCC test case I agree with Catherine that a run-time test case 
will be fine, and actually inevitable if the linker fails to fail.

  Maciej