This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Petar Jovanovic <Petar dot Jovanovic at rt-rk dot com>
- Cc: "Moore, Catherine" <Catherine_Moore at mentor dot com>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 17 Apr 2015 20:36:20 +0100 (BST)
- Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
- Authentication-results: sourceware.org; auth=none
- References: <6a22-55314b00-5-5cf51280 at 159592552>
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