From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68949 invoked by alias); 15 Oct 2019 18:23:54 -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 68940 invoked by uid 89); 15 Oct 2019 18:23:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.8 required=5.0 tests=AWL,BAYES_00,FORGED_SPF_HELO,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LOTSOFHASH,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:4534 X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr10052.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.107.1.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Oct 2019 18:23:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sG45sO++YDjlIU6NQzXHaS050uYSCPENSN7vGdMTTQk=; b=vLj2tGmmR6ZeXMnUfWlc+BQNqus1stDURSHcwAhLAHys0Qiu53xGNjywXkWSCqRT5bb6rE7kdwyQbFpKWO2Rf9Z7OPl4QdljO/myy5NjQ3naR7SfEHBl0hYp+nKzhtyrmls93QXULKI269TveSKQFWxGg5Thhs2z+fRIHr5kMss= Received: from VI1PR0802CA0012.eurprd08.prod.outlook.com (2603:10a6:800:aa::22) by VI1PR0801MB2016.eurprd08.prod.outlook.com (2603:10a6:800:82::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 18:23:48 +0000 Received: from DB5EUR03FT053.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::204) by VI1PR0802CA0012.outlook.office365.com (2603:10a6:800:aa::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.18 via Frontend Transport; Tue, 15 Oct 2019 18:23:48 +0000 Authentication-Results: spf=temperror (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;gcc.gnu.org; dmarc=none action=none header.from=arm.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of arm.com: DNS Timeout) Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT053.mail.protection.outlook.com (10.152.21.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Tue, 15 Oct 2019 18:23:46 +0000 Received: ("Tessian outbound 081de437afc7:v33"); Tue, 15 Oct 2019 18:23:46 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7c74145319cd3662 X-CR-MTA-TID: 64aa7808 Received: from 89affce41dbf.2 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.10.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1CCE17B5-4C88-4914-AE56-A849E8CD80C5.1; Tue, 15 Oct 2019 18:23:41 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp2057.outbound.protection.outlook.com [104.47.10.57]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 89affce41dbf.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384); Tue, 15 Oct 2019 18:23:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PwwooIxighpd8toPIYMXS7ZY/DNbgzdj6uepHf24dBQ+IM0dea0g1Wiw5w5VF5pnusDkBhFkVbO/XKk1Z3yNjqdS9y40jIdMFNYCqDgMUT2eTXnrjWv47E2RONgyysc1rR7Zk1u7FhiS3ZukoIaR6rNRsitlyoJnQwD+5GMVEyd9KZOQ1stWk86XoTCvVqTKvvD5x41pTiWlG1I9uR8aoeL5+m5DipXAkzcE6obI3r8Sxc7+9S8qwmOQLYf92M69XzGWzNbJYGWA5zjej4+1wVMuTfHJ/Do/vo+IFH6vk5J2v6X0NMDB9SnfurUekfhhacRCPZfLahtYIWFUAbzHKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sG45sO++YDjlIU6NQzXHaS050uYSCPENSN7vGdMTTQk=; b=cHFuftf8cgZHLK3RQVNw6OXvOi3s/a5tyEy6LPvNL7DgYtY02CJhdBFE0goMKShV/QSpOdPsbtqxlDPVc3zum7lHo7HVjhX02IzlW8MLHZiOgjUiuTIBcu6sbs+5qJmV8nYYqhlDVEure6zFEDLSP6NPXWMCq0EwZnk7fVjUd+k7NTVS6iW08C5zNIL0nVjBw01ULSswttImv6kVlfEFpeEIqwS8k9D/5hOOLLTTBdf8Hp/PXFcmCXO2Q5tRlMqBZrW2Bk1UpUpeqOyffo+L8DX7UUeunPC1WePPZpSzVtg0ZVyGGKNCDDJoT1y05nAUlFJSdhsukMVeqleUcC/b7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sG45sO++YDjlIU6NQzXHaS050uYSCPENSN7vGdMTTQk=; b=vLj2tGmmR6ZeXMnUfWlc+BQNqus1stDURSHcwAhLAHys0Qiu53xGNjywXkWSCqRT5bb6rE7kdwyQbFpKWO2Rf9Z7OPl4QdljO/myy5NjQ3naR7SfEHBl0hYp+nKzhtyrmls93QXULKI269TveSKQFWxGg5Thhs2z+fRIHr5kMss= Received: from VI1PR0801MB2127.eurprd08.prod.outlook.com (10.168.62.22) by VI1PR0801MB1935.eurprd08.prod.outlook.com (10.173.72.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Tue, 15 Oct 2019 18:23:38 +0000 Received: from VI1PR0801MB2127.eurprd08.prod.outlook.com ([fe80::38cb:bfb8:b869:7cb8]) by VI1PR0801MB2127.eurprd08.prod.outlook.com ([fe80::38cb:bfb8:b869:7cb8%12]) with mapi id 15.20.2347.023; Tue, 15 Oct 2019 18:23:38 +0000 From: Wilco Dijkstra To: Richard Sandiford CC: GCC Patches , Ramana Radhakrishnan , Richard Earnshaw , James Greenhalgh , Kyrylo Tkachov , nd Subject: Re: [PATCH][AArch64] Fix symbol offset limit Date: Tue, 15 Oct 2019 18:27:00 -0000 Message-ID: References: , In-Reply-To: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-ms-exchange-transport-forked: True x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(376002)(136003)(396003)(346002)(39860400002)(366004)(189003)(199004)(26005)(11346002)(186003)(52536014)(55016002)(6436002)(4326008)(6506007)(102836004)(478600001)(33656002)(256004)(14444005)(54906003)(6862004)(446003)(71190400001)(71200400001)(76176011)(476003)(9686003)(486006)(25786009)(6246003)(99286004)(66066001)(316002)(5660300002)(14454004)(64756008)(76116006)(81156014)(3846002)(66446008)(6116002)(305945005)(86362001)(74316002)(7696005)(8936002)(7736002)(6636002)(81166006)(2906002)(229853002)(66556008)(66476007)(8676002)(66946007);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0801MB1935;H:VI1PR0801MB2127.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: O9cgdn6ZrFGQIL99ORRSlDS/peCthMGR5vBudegfUdhpOYVghR5BY7HL5lPTLp0JkijuYrgpVCFMY1/VytjvUxlJTG30t6GH/EfF35dNMKb4QgwDqNCFJvAqp83EEyjqDqGpa7CoyWR/hbg/3VhBfV79D9q72Oi1FrWT3jcsCZAkJbGULm3kKbdIr6qTrG8AF6H391lXUb9JDBV9AEE0w5bZASqIHFXeywM5HGVYuO0FmQJBvyUdTri6e1LLDbVGMtcbJUXfWcoI3bM+vPFQI0ojS4GnJiG9wvtgmvVbW3yFsluajI17vzM8Gohkd4DtjTsuk0ntwuPgMDkx9sgKf8ZuX7Ud2zyJyZBWBlF3mC86Rjlmy9Xb0s6T/PRxFnKITQcalAEGehXP456qhdmdmi3hpG3lo6e+N7f5nVoKp3Y= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; Return-Path: Wilco.Dijkstra@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT053.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: aa4197af-1f6b-485c-183b-08d7519ccc56 X-SW-Source: 2019-10/txt/msg01126.txt.bz2 Hi Richard, > Sure, the "extern array of unknown size" case isn't about section anchors. > But this part of my message (snipped above) was about the other case > (objects of known size), and applied to individual objects as well as > section anchors. > > What I was trying to say is: yes, we need better offsets for references > to extern objects of unknown size. But your patch does that by reducing > the offset range for all objects, including ones with known sizes in > which the documented ranges should be safe. > > I was trying to explain why I don't think we need to reduce the range > in that case too. If offset_within_block_p then any offset should be > OK (the aggressive interpretation) or the original documented ranges > should be OK. I think we only need the smaller range when > offset_within_block_p returns false. Right I see now. Yes given offset_within_block_p is not sufficient, we coul= d test both conditions. Here is the updated patch: diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 7ee31a66b12d7354759f06449955e933421f5fe0..31c394a7e8567dd7d4f1698e5ba= 98aeb8807df38 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -14079,26 +14079,30 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT off= set) the offset does not cause overflow of the final address. But we have no way of knowing the address of symbol at compile time so we can't accurately say if the distance between the PC and - symbol + offset is outside the addressible range of +/-1M in the - TINY code model. So we rely on images not being greater than - 1M and cap the offset at 1M and anything beyond 1M will have to - be loaded using an alternative mechanism. Furthermore if the - symbol is a weak reference to something that isn't known to - resolve to a symbol in this module, then force to memory. */ - if ((SYMBOL_REF_WEAK (x) - && !aarch64_symbol_binds_local_p (x)) - || !IN_RANGE (offset, -1048575, 1048575)) + symbol + offset is outside the addressible range of +/-1MB in the + TINY code model. So we limit the maximum offset to +/-64KB and + assume the offset to the symbol is not larger than +/-(1MB - 64KB). + Furthermore force to memory if the symbol is a weak reference to + something that doesn't resolve to a symbol in this module. */ + + if (SYMBOL_REF_WEAK (x) && !aarch64_symbol_binds_local_p (x)) + return SYMBOL_FORCE_TO_MEM; + if (!(IN_RANGE (offset, -0x10000, 0x10000) + || offset_within_block_p (x, offset))) return SYMBOL_FORCE_TO_MEM; + return SYMBOL_TINY_ABSOLUTE; =20 case AARCH64_CMODEL_SMALL: /* Same reasoning as the tiny code model, but the offset cap here is - 4G. */ - if ((SYMBOL_REF_WEAK (x) - && !aarch64_symbol_binds_local_p (x)) - || !IN_RANGE (offset, HOST_WIDE_INT_C (-4294967263), - HOST_WIDE_INT_C (4294967264))) + 1MB, allowing +/-3.9GB for the offset to the symbol. */ + + if (SYMBOL_REF_WEAK (x) && !aarch64_symbol_binds_local_p (x)) + return SYMBOL_FORCE_TO_MEM; + if (!(IN_RANGE (offset, -0x100000, 0x100000) + || offset_within_block_p (x, offset))) return SYMBOL_FORCE_TO_MEM; + return SYMBOL_SMALL_ABSOLUTE; =20 case AARCH64_CMODEL_TINY_PIC: diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c b/gcc/tes= tsuite/gcc.target/aarch64/symbol-range-tiny.c index d7e46b059e41f2672b3a1da5506fa8944e752e01..fc6a4f3ec780d9fa86de1c8e1a4= 2a55992ee8b2d 100644 --- a/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c +++ b/gcc/testsuite/gcc.target/aarch64/symbol-range-tiny.c @@ -1,12 +1,12 @@ -/* { dg-do compile } */ +/* { dg-do link } */ /* { dg-options "-O3 -save-temps -mcmodel=3Dtiny" } */ =20 -int fixed_regs[0x00200000]; +char fixed_regs[0x00080000]; =20 int -foo() +main () { - return fixed_regs[0x00080000]; + return fixed_regs[0x000ff000]; } =20 /* { dg-final { scan-assembler-not "adr\tx\[0-9\]+, fixed_regs\\\+" } } */ diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c b/gcc/testsuit= e/gcc.target/aarch64/symbol-range.c index 6574cf4310430b847e77ea56bf8f20ef312d53e4..d8e82fa1b2829fd300b6ccf7f80= 241e5573e7e17 100644 --- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c +++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c @@ -1,12 +1,12 @@ -/* { dg-do compile } */ +/* { dg-do link } */ /* { dg-options "-O3 -save-temps -mcmodel=3Dsmall" } */ =20 -int fixed_regs[0x200000000ULL]; +char fixed_regs[0x80000000]; =20 int -foo() +main () { - return fixed_regs[0x100000000ULL]; + return fixed_regs[0xfffff000]; } =20 /* { dg-final { scan-assembler-not "adrp\tx\[0-9\]+, fixed_regs\\\+" } } */