From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060.outbound.protection.outlook.com [40.107.20.60]) by sourceware.org (Postfix) with ESMTPS id 92C353858002 for ; Mon, 27 Jun 2022 14:03:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92C353858002 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8cSpjcaQGkxNxp+LhcE9Oihf9z64StNApHsefcJvOKPld89GRaOc+Qpmi+o2o1NGNMPPXj2qSZQFyFE+9UniSMcIFxV0wAVlAPom1CMuGqR9IcuP2p0A4uSVe9LNrgvp+rCBDXyHNIWsrcHtwyzRrSyen6+Q8apEfZoktH2bXO2AmUzHaMhBwF7QdJD4yq/i4CfocsUgjjnr+dS+F6WrP2rJ9h9I3PcZJjV3JDx9jc5rGLb8rtYmSn7IfR58vQXrsRZBSK9ncAWv5EcI7sHDhycPQ/OiuLdNmcOogL1/ZR1zFWwYWhSFvokWqrOhQGES/aHJqsZTJVqKZmapsivOA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v2shp9sVnmXMnbmy5oVCqFSQjYRsKD71GlWCZj+mIGw=; b=UbS/m5Fa+amvGS5aNDmqH8axTvDopIt9viANWQmBEx+9+frXhbfxLUHTeriGfG3ki8bUUrryQBYIY66aIWG3Jn9NpMq2njNih1yP+LvzTSSdmIWjOqNf3RKi4lzBvF2rjpHw1ozB9hK6xPMmwW8kp9IAnmZNWsLkJ82RBZnzXjBDo4KaTRQTFGY+YUsvXwDuPCNH4TGr4GXGwpeKOifRUROwTdrUWb3l4Df9d0/mpbLfs2c6l3+DRH0DMmQHEkShtbANJfHm3xcpp8AJanvjtVQ8dEuYXoCUZozh4AfR7ux74pTPbICzhCt6rAawxdo++MZ1DOtj+jEGqJSoy1AdOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Received: from VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) by VI1PR0401MB2559.eurprd04.prod.outlook.com (2603:10a6:800:57::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.18; Mon, 27 Jun 2022 14:03:33 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::dfa:a64a:432f:e26b]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::dfa:a64a:432f:e26b%7]) with mapi id 15.20.5373.018; Mon, 27 Jun 2022 14:03:33 +0000 Message-ID: Date: Mon, 27 Jun 2022 16:03:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Arm64: assembling adrp with operand involving . Content-Language: en-US To: Nick Clifton Cc: Binutils References: <2b85b841-e617-618c-9a3d-50101faded80@suse.com> <84567b31-7ed1-a377-7d05-8b6596871ae7@redhat.com> <0ce6816c-a77f-6f01-d1fc-bd6507fbd02c@redhat.com> <94e3756e-27fa-649e-46b8-ac689b8f739d@suse.com> From: Jan Beulich In-Reply-To: <94e3756e-27fa-649e-46b8-ac689b8f739d@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS8PR04CA0078.eurprd04.prod.outlook.com (2603:10a6:20b:313::23) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f598d677-47c0-4586-e3cf-08da5845d25f X-MS-TrafficTypeDiagnostic: VI1PR0401MB2559:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DgdtfGngenIy0Rzs4ttFXhkAz15g2Ar4MNGY8XmMyNND6HlMBP/AcHMHN7S2m04+1F/6tPRPtD84r5H80IV53zjLfdGvOrha9V0/rD/SrRLPpobbuJKSHSiVO1BK/7Vp4LsDDeV9WoHzO8fYrVh9e3JQgDVFCcwySYqIGfo+9z3nl9UZTulxlmo7xdhn03lG0lXejp7tRnjjMhNhCZ7QYxRc7GCA7Nhjkv6JwmEP2ptZgjKUkvf+CjwDv0kdHOqqrDHlc2UkvvFdl5PAFdnv2aVqAe2N8N42Khtr1YIr8tkAxzc4qG0vJ4xFUQsfo11ooVpjODLKPafZ1KDpzZjIVSGt0zPISwlA5whoh1f+Ev7291sNeasJnH3WATX0YqSEf3nxwNO/RUZBJqzPQkGgZH33wUjsrpubgUIpOoYKnjb1myD2MA68U2eYr5mI+PA9HFFO4IpOQmLRQTmuvlW5RsWarW4JJQLdrp8O7rPBNpDto2EA1FyBGDhio4Wzzd1Vd73niXxMafOve5N1H0TTX3F2caAz9SPj0G21Lroc7dkFXPgF4HEsJujykLfkvNAznF8lHDCsByQInBlxG6yQd+YCX/mq5vpSqE8h9i533108aEyA3QBvAoQz0H6EtDng1ClLui6dTJYwa8S89/fjjwE/XQ3uy4c6BFoBLy+GwC4Km8LQieohqXi6jgaiyqRlmmlLVTcQBZb7ZI5lBASmxNmC+XUDh279QgW2Ud6J7zXp3EFmupPKbLh294hYrvi5OARuam3Z4n1InVrhsNCAoBNpimLEuUeuzx8XyNMNE3i9pPlJYHFm7JSpaoAohqnvuLKMWJIVCZSrEowwLEpAFRMHOlDFD7KY3/T7QAX3044= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR04MB6560.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(376002)(136003)(396003)(346002)(366004)(39860400002)(26005)(53546011)(6916009)(5660300002)(41300700001)(2906002)(6512007)(2616005)(6506007)(478600001)(8936002)(31696002)(66556008)(86362001)(38100700002)(83380400001)(186003)(31686004)(66946007)(8676002)(4326008)(36756003)(316002)(6486002)(66476007)(132733001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OU5rQVVaT0dBRDYvcHZ4RkRCN0pvWkN4K0EzQXFmWTJvZzF5MURhbHVVM3dS?= =?utf-8?B?QVlpZUhqVUtmblhab2plei9SaUJaeHZRZnlEYUd0YmhUUi9ycGxlRGFTeUtQ?= =?utf-8?B?dWFkZU5WY1p1bG5XdkkxZ3VIYVdXRWVueFlCajV6QSs5cFVBdk1xWDdmaDBs?= =?utf-8?B?UERtemNrd2FxbW5pQ0dpQ2F6WHh1cjR2Y0FCV0U2YVF0ZURpTWJVV1JraWFv?= =?utf-8?B?MUxnN3VQMW12UmRuZU42WUVWZFgxSm92ZXJ4UXczdWwvb09vZjFiQUloaWdF?= =?utf-8?B?eWNlNWhmOFhMZjg5Ui9GekVqNXVrUm53UUVlSThzSnN0dWRzOG51SzVUbTRV?= =?utf-8?B?Q2gzMlR1Wm5XbDdXZ0dmcUVZZ0U1NHY5QzdWLzRUT3hocTNZcHpYL3RvNWhj?= =?utf-8?B?eWlkMzNpZ1pNd1Yyaklqd0pRdXEydmZLZzd1VUxDSlFzTjdZaXRkWUNZOXVl?= =?utf-8?B?SEdFeDRJSWV2SWVsUVBBVFFFK2ViYU5yN01QRllhWFp4LytoK2RpYWgxVXZF?= =?utf-8?B?VGxJZGFVS1c5dDJxZFZJOHliL1VURFZzOFhlRWxtM3BvS3BYb0tXWi9OQ1VX?= =?utf-8?B?cXVQRXZMZHlzZS94Vmc1dW5wRlRXTXNxbWVmTVFxQjIyb1FWbW84c0ppb3Bp?= =?utf-8?B?VnZwZFNhcFV3QjEzT2drNmxicmdvQS9CMVVCSUp5ZkJ1L3BCRUZUcitscFBz?= =?utf-8?B?S3lBN290M2hNbU9KZzM0NUQ1YzZlVzBxZFlNelMyQ1NLeThpZjEyQ0xGUVdu?= =?utf-8?B?RVowS0pEWDQ0NmtKZzgrZHRxdU1iSUl3SlljUVZWS2R5NUZYNUcxS0pWQ0VD?= =?utf-8?B?TUc1NFhTbjM5cnpFMGRYSnlObW9iZ3VMRUJianhOd3k4WGdYbENaTVBUQk80?= =?utf-8?B?NFV3cEZuRGw5a1BtYWFTSXRTKzRUY2tJaTk5MkNobHF4OEN3ZUg0dU5Wak10?= =?utf-8?B?S3dNOEhmUHc4R0ZMRXB5aklRbTdvSDhFMElhTDdZTW9iQjN2MCs2UExwd3BM?= =?utf-8?B?T2RkeHFxekgrNjhNcmNPd1BNRXJTdGcyaXY2ZlM3Rno1eHdGRGVvNFFKSWV3?= =?utf-8?B?SERkMURlT0kwR2lsUWt1T0dKN0MzNnNJczkyQ0k4eFB0NE9PQklyWWprZ29V?= =?utf-8?B?ZWdOTjUxa0hwNUo3UG5VNmFRdmdIL1ZBT2RWREV1cGI0ZmhTV1RSZ01VYWJr?= =?utf-8?B?YzlTT3lOMHlmVUFQbmRscVV5MFdCblVxSDJDWXZtTDhsdWhCSDNNMjlMajV2?= =?utf-8?B?Y2w4d1Y0c2NGeTN3VGswWVdVY29KMDZscEhLZE5jN2RFVnJsK2lYUkpOU1dS?= =?utf-8?B?R2NseDdMN2x5eWw5WXpOcVF5VWJrcUl3aVAvM1lLVVlGaGlzbVd2OGJ4QWNj?= =?utf-8?B?dS9jWnZPWi9FRGQveXUxYWt5ZVNRVEVCNktEc3BSekpQL2Y4SUZjQlZmTXBz?= =?utf-8?B?UmN5dXQ3Uldtek1yMkVDVktrcXBpMmpuSElONWJMZUtnTnJ4RGZBaXdWaU5p?= =?utf-8?B?TWh3QlNhOWNxVFFhNmFZVi9tOHljTmxkY3pQbXBKK212NWtsRFJCKzk1MThL?= =?utf-8?B?dXlTTU9QMVFLZXBQV1BSdGF4MHJzU2NIOXRNM2RDTlJXbTI4K0gzUHAvTzZz?= =?utf-8?B?U2QyMUttYUZOMnhPTWo4TTBPOFhTUDVEakNNci91YXltV3hyOERLcXZ2L2Nq?= =?utf-8?B?bCtRTEZUOGxMaGdDUEpheU40WW41MGdodjRVWUhSc2hIUE9aeVQ2TFZCb3dL?= =?utf-8?B?a3FSM1c5ZHpzeVlLYkk1SFFQdXZ4eFBoY1VDL2pOTStiRFlaS1NsazYrM1FO?= =?utf-8?B?NW9pbDZyV0RlQkR3YWZqS0o2bjFHVklRM3NxR21kRlR1ekNJZUtNZHh0aC8x?= =?utf-8?B?SW1MVXNzaXpBTDlzRlYxUDBOcyt3Z25RSm1kNlliT1Evdnlham00a3VuYVh1?= =?utf-8?B?dHFOZFZIc2tuMXVxZzd5Z1UreVR1Wlltb1ZSOGR1VFVlbzdwK0tidTVMQXJN?= =?utf-8?B?bnlOcVEralg2OGJFZ3NORko0N0JueGxGcm9MOXIxWXU1bmJXRVMweVZ4VWNq?= =?utf-8?B?d1ZvYkl6OUpRWjZjdXN4L1RhOXFaYzI2RzhFTkhCZXNSdFg3RnhMVC95YXMr?= =?utf-8?Q?1bdF3G+U0WALxYraxfrNU62wm?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: f598d677-47c0-4586-e3cf-08da5845d25f X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2022 14:03:33.3864 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: q0AJKkqCXccAaeDQR/gwt+uz137F2xofFAH4k1LJpbBsF/Xe3+lCRP/2XGbia3JGx0v4Ou974zcPQgwXK8Wquw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2559 X-Spam-Status: No, score=-3030.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 14:03:40 -0000 On 18.05.2022 09:26, Jan Beulich via Binutils wrote: > On 09.05.2022 17:21, Nick Clifton wrote: >>> --- a/gas/config/tc-aarch64.c >>> +++ b/gas/config/tc-aarch64.c >>> @@ -604,7 +604,7 @@ aarch64_get_expression (expressionS * e >>> input_line_pointer = *str; >>> in_aarch64_get_expression = true; >>> if (defer_resolution) >>> - seg = deferred_expression (ep); >>> + seg = /*deferred_*/expression (ep); >>> else >>> seg = expression (ep); >>> in_aarch64_get_expression = false; >>> @@ -8824,7 +8824,8 @@ md_apply_fix (fixS * fixP, valueT * valP >>> >>> /* Note whether this will delete the relocation. */ >>> >>> - if (fixP->fx_addsy == 0 && !fixP->fx_pcrel) >>> + if (fixP->fx_addsy == 0 && !fixP->fx_pcrel >>> + && aarch64_force_reloc (fixP->fx_r_type) <= 0) >>> fixP->fx_done = 1; >>> >>> /* Process the relocations. */ >>> >>> But when using a transitive equate, the intermediate symbol is then >>> used, which still doesn't feel quite right. Hence my thought of >>> doing yet more evaluation of the expression. >> >> I do not get what you are saying here. Could you provide a small >> example of code that might experience this problem ? > > .text > > .set x, 0x12345678 > .eqv bar, x > foo: > adrp x0, x > add x0, x0, :lo12:x > > adrp x0, bar > add x0, x0, :lo12:bar > > With the proposed change, the first two relocations would be against > *ABS*:0x12345678, whereas the latter two relocations would be against > x. (Prior to the proposed change, the first two relocations are > against x and the latter two against bar.) > >> Still, given that this approach appears to be simple, self-contained >> and correct, I am inclined to think that it is the best solution... I wonder whether we can come to some sort of resolution here for 2.39. I'd be happy to tidy up my patch and submit it, as long as its downsides are understood and deemed acceptable (i.e. at least slightly better than the present state). Jan >>> If, otoh, the symbol references in the relocs are indeed meant to be >>> as they are now, >> >> As a general rule, this is one of those things that the target's assembler >> language specification ought to define. Of course not all targets do have >> a well defined assembler language specification, so then we have to do the >> best that we can. > > Hmm, I would have thought such rules ought to be largely arch-agnostic. > > In this context, do you have any thoughts about "Arm64: follow-on to PR > gas/27217 fix"? I don't really feel comfortable committing this without > either you (as the author of the original fix) or one of the arch > maintainers having signaled agreement in some way. Of course, depending > on the further route taken for 28888 some (most) of what's done there > may disappear again (alongside parts of the original fix for 27217). > > Jan > >>> then the only other solution to the problem with . >>> that I can see is to introduce yet another expression parsing mode, >>> which would resolve . but defer everything else. One problem with >>> skipping evaluation of the expression is that in >>> >>> .text >>> >>> .set x, 0x12345678 >>> .eqv bar, x >>> foo: >>> // adrp x0, x >>> // add x0, x0, :lo12:x >>> adrp x0, bar >>> add x0, x0, :lo12:bar >>> >>> .set x, 0x98765432 >>> adrp x0, x >>> add x0, x0, :lo12:x >>> adrp x0, bar >>> add x0, x0, :lo12:bar >>> >>> the two pairs of relocations against "bar" necessarily can only >>> reflect one value, while "bar" being a forward ref would suggest >>> x'es original value to be used in the first pair, but x'es final >>> value to be used by the latter one. >> >> Which would definitely confuse the programmer. So I think that we >> should avoid this route unless specifically required by the target's >> assembler language specification. (IE, for the AArch64, I could not >> find anything saying that this behaviour is required, so I think that >> we should not go down this route...) >> >> Cheers >> Nick >> >