From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31291 invoked by alias); 15 Jun 2017 15:13:58 -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 27706 invoked by uid 89); 15 Jun 2017 15:13:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=million, Hx-languages-length:2261, satisfaction, his X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Jun 2017 15:13:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 899A4344; Thu, 15 Jun 2017 08:13:58 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7A4C13F41F; Thu, 15 Jun 2017 08:13:57 -0700 (PDT) Subject: Re: [PATCH v3][AArch64] Fix symbol offset limit To: James Greenhalgh , Wilco Dijkstra Cc: GCC Patches , nd , marcus.shawcroft@arm.com References: <896d038e-f19f-d95e-2213-f3360ba71b28@arm.com> <20170614140702.GB8010@arm.com> From: "Richard Earnshaw (lists)" Message-ID: <31845e36-14f3-eb1e-ef11-5bcf70a11b15@arm.com> Date: Thu, 15 Jun 2017 15:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170614140702.GB8010@arm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg01122.txt.bz2 On 14/06/17 15:07, James Greenhalgh wrote: > On Tue, Jun 13, 2017 at 03:00:28PM +0100, Wilco Dijkstra wrote: >> >> ping > > I've been avoiding reviewing this patch as Richard was the last to comment > on it, and I wasn't sure that his comments had been resolved to his > satisfaction. The conversation was back in August 2016 on v1 of the patch: > >> Richard Earnshaw (lists) wrote: >>> >>> So isn't the real bug that we've permitted the user to create an object >>> that is too large for the data model? >> >> No that's a different issue I'm not trying to address here. The key is that as long >> as the start of the symbol is in range, we should be able to link. Due to optimization >> the offset may be huge even when the object is tiny, so the offset must be limited. >> >>> Consider, for example: >> >> char fixed_regs[0x200000000ULL]; >> char fixed_regs2[100]; >> >> int >> main() >> { >> return fixed_regs[0] + fixed_regs2[0]; >> } >> >>> Neither offset is too large, but we still generate relocation errors >>> when trying to reference fixed_regs2. >> >> But so would creating a million objects of size 1. The linker could warn about >> large objects as well as giving better error messages for relocations that are >> out of range. But that's mostly QoI, what we have here is a case where legal >> code fails to link due to optimization. The original example is from GCC itself, >> the fixed_regs array is small but due to optimization we can end up with >> &fixed_regs + 0xffffffff. > > Richard, do you have anything further to say on this patch? Or can we start > progressing the review again. > > Thanks, > James > Yes, I still believe that this is a bug in the way we've documented the -mcmodel=tiny and -mcmodel=small options. -mcmode=tiny should read: @item -mcmodel=tiny @opindex mcmodel=tiny Generate code for the tiny code model. The program and its static data must fit within 1MB. Programs can be statically or dynamically linked. The limit is not enforced by the compiler, but if you exceed the limit you may get errors during linking saying that relocations have been truncated. It's the same basic text for -mcmodel=small, except that the limit is 4GB. R.