From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86604 invoked by alias); 17 Apr 2015 19:36:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 86594 invoked by uid 89); 17 Apr 2015 19:36:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: cvs.linux-mips.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (148.251.95.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Apr 2015 19:36:25 +0000 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S27010677AbbDQTgUf-cO2 (ORCPT ); Fri, 17 Apr 2015 21:36:20 +0200 Date: Fri, 17 Apr 2015 19:36:00 -0000 From: "Maciej W. Rozycki" To: Petar Jovanovic cc: "Moore, Catherine" , Matthew Fortune , "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro In-Reply-To: <6a22-55314b00-5-5cf51280@159592552> Message-ID: References: <6a22-55314b00-5-5cf51280@159592552> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00931.txt.bz2 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 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