From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from de-smtp-delivery-102.mimecast.com (de-smtp-delivery-102.mimecast.com [194.104.111.102]) by sourceware.org (Postfix) with ESMTPS id 2D1B33858D3C for ; Wed, 18 May 2022 07:27:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D1B33858D3C Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2054.outbound.protection.outlook.com [104.47.13.54]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id de-mta-28-y_c0Rs98PQSzTM7gvksIYQ-1; Wed, 18 May 2022 09:27:08 +0200 X-MC-Unique: y_c0Rs98PQSzTM7gvksIYQ-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Id3tytjO0bqzraodqV66nEnjUE+oish/mM/zYiFZuMUP2dHnRRg18a2jPzbr81UPdMO1q+T80WdSmuTXZ9ThDmgvlL/ONS+KHHln9IXFmjn8qyXD4OodsLhu8D0d4OwGBDUGXw+HuPAFqYRR1Ve9c9iCRAcW7J1Qw6clyHvnwqrbHR0uBY+UgxnB4xeYYGSzNP5lmOkPZbBINCmD1ok6XZrLOtOj0yqAXq+BFXPKZ1GBmwfUso0LJF5ECU4BjnJGCgewn50AR/ioFjSVs3iKhQ24GncET1MUvCq+RI7AS3pqKyEb4CeLTi0c65eMhVuj2q82m0ONkyKJnidNAMZnfA== 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=12DW3cjlXKSVDXzWjnJyBYh/nrerXsC/JO+yD4XdeXw=; b=hA7BsURrUINz0i+VCcFSV1vMNFBAPWm4tFCVxlpVeiUzAYGf7V8wHmjTYA01pwKbuWojS4iMcHnC7i+mi3Lf3K1HbBQ0joDZ7uMRCGmerVWHFU5MWzMQ8TvAah5d3rdZgKlsO//kf3/KGxvxSMogI8sIS3kNpYeSgNmAEgiI96cyA+M++gkGl4t59HvNHXTGb4V4CFRO0JjLtIqqm0O7Ug/CW7h0gpVOdr8NkE2FqP8xlvF9N2D+5SmF702mS7VNEYbDdny7eL/c0pfxKO6CkwsZA6Y1zynOnjeQ5+fs+O7aSr1t2BpehWf7os+eZ/ZFIo6yukunq0QNZjApsZCruA== 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 HE1PR0401MB2268.eurprd04.prod.outlook.com (2603:10a6:3:24::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.14; Wed, 18 May 2022 07:26:06 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::91b8:8f7f:61ac:cc9b]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::91b8:8f7f:61ac:cc9b%7]) with mapi id 15.20.5273.014; Wed, 18 May 2022 07:26:05 +0000 Message-ID: <94e3756e-27fa-649e-46b8-ac689b8f739d@suse.com> Date: Wed, 18 May 2022 09:26:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.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> From: Jan Beulich In-Reply-To: <0ce6816c-a77f-6f01-d1fc-bd6507fbd02c@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM6P195CA0096.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:86::37) 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: 873120e3-073a-47f5-603a-08da389fab94 X-MS-TrafficTypeDiagnostic: HE1PR0401MB2268:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NfvfVUuzfAIb7Y2R0U49gIjZjEkztNVwWpfg7S+ojwc3fPZjzGp6hdt8POuEF1l/6ExC/JHOhempr0gAiER21Vxoyw+9DMr331WxaWGyTOf+l7t9+q3faWKUAPpADA8IISBBI+mwu38j7BaGjf0D/r4wP537gJcslVvF3FRIkeH+yYGWLc7qSMGctYzPdOM8uCc5Xf1XgQbJFSkj1yo4/qsaRIGo+AfpoyvDmpaGK1by/+IS6TRbbsXCngXG4/XQGdbj8aJN1xWzU5pYVjRDfYhc7Mk+lHrY3hG5CjBGPVLctuczGuSGKwk13MARdJBCZvgIZDda5bkiuWOiBNTP+QG3l5X+4zGT2M5HiH05PZJZDVNNz7YSt3g6oyZMeIhku47M3rBvOUjufCBGTvazq2cHzatPZQfmf7tGb2hS5XMaN1WTkLw4l+aH/TN0a0RfMwRTD6JvAbNZWiNIeVQyDPQrVSls1oW8L0pXbmBRfDtjvvoAYRtW4z0bcgq+lWlsj2RNgQSKuYHQII4eu4QH2AzXzRmoWQkddveRV5lhD71CLlQ9E5C4hQKIuwjBs7egFGfSNqZ88VfSHR72XjKucPcUXDkI6XU52TV+w8Bd/PS8GDvtHu6ecd6dBYYookRz4AlTqXd2qmrZC07ffGVZb2f5GEWVda+7PkLYYarTv32SIHuKsEHCdpfgh51G3SozNy8rv2U78ssVZvBerpbIXlcXpHZUrY3We6UYZDn8saoOTSaiytGkv+hV+WlTPRfxpYvs/9XMEYcb9bGBIYwIpA== 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:(13230001)(366004)(8936002)(6486002)(83380400001)(316002)(6916009)(508600001)(4326008)(66556008)(6512007)(53546011)(38100700002)(186003)(2616005)(86362001)(66476007)(8676002)(31696002)(66946007)(5660300002)(6506007)(36756003)(2906002)(26005)(31686004)(132733001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T0d0SVZqbkNuME9vQnNxWUZqZVNjOVFVaHUvWmNFVm1JNkZoamI5V1h6UHBT?= =?utf-8?B?QzRNbW1iRGI1SDBLTVBjbytTTnpVUlN5bTRJQWlQa2dSeDJkSFNFNXQ1Q1ZO?= =?utf-8?B?ZW4wbkVKQWR2SjkwSnNuVkJjeDBabjM1TG5qK3ZPOUVLU2pUemszWGFkSFl5?= =?utf-8?B?M2JBaEFxSTg2V2Y1YlBaTjVKV0t4b3lucHpsbEVHZ1FaSGZ6SkZmejJoVzFL?= =?utf-8?B?MmN2ZkJjTnFqNnF2S2drK09LdG82aGtwZDdNMkdBbGFrM2lnNm1tV2FrWFNZ?= =?utf-8?B?MXJWMVdJTDZ3aHhUWWpTMHJKRlFqeUFZV29KNUZlK3I5UDM5TkdmLzAzR3g0?= =?utf-8?B?OEg1ZFByOGErRXY5NWZhOGd1eWVRN0FCSGl1YVM5RHFJUDJobk9uS0xzQURu?= =?utf-8?B?Y0V6U2txVVhsem4zRlFqSFVjaWFJZmlURGdEN0tkT1dYeUVHZXVieXhBRkVX?= =?utf-8?B?VGZ6WWlSRGZjVy9RM0NlWng0UGRVUUluS1ROVkszZmN6SzBGREIxVjdPbURm?= =?utf-8?B?R1VIQm5SY2JBSFRDT0VJT2VWN2pLclg4KzVaYWRSMTRGRmhxTWVRdDVFMmVW?= =?utf-8?B?VjB6Vlo3bVVqanI4cVoxWVFEUnJheXhOWUdHM1BIS0w0ZlEzS3ZhUDMrWTIr?= =?utf-8?B?dGhiaWFsbnN2a01yeXRsc280Wmh4Z0JtZmd5bDNEUG5XK0pSZGVhb3RGd3RB?= =?utf-8?B?SXc2WDJjTWxsVTQ2MFdGK3JtYlRGekpBS3FCQ0Y2SkZmZTVyS3Vtb2RRd2lJ?= =?utf-8?B?by9idS9vN1NOSC9RYzU1U2x0OU1MRU52OHN5V0JwMk9WSm1VVGg1cmVXcXJI?= =?utf-8?B?QlZiKzBvWDMvZWV0Yzh3QlZUV2tnOEtONnlxUWVXZE9TSDFnY0NoNkM5UEZZ?= =?utf-8?B?eEo3K0VhK25JRURTeXVST1VyUVZPM2NDdVNMMTFic1BMM1ZFbFQ3S3l5eUJi?= =?utf-8?B?RVJIaDJrK0ZEVHZtUC9BVE5NTHZDMkdPNXV2eUs3S1J5OU9PZXRpUHZvY3BV?= =?utf-8?B?N1JKNG9OQjhVOC9WcW15WXJaRVdwS3FiUFp0K08vM3FBUktoT3QwUWFsa29U?= =?utf-8?B?TU9xV3c2RUlvQ3JrUlVIeXNVcUFsK3RoYVFxNUpEVEp1dE1TVFBmZm1hWS92?= =?utf-8?B?Q1Y0YXJ4WVhLaGhkVzFKRk41am1xemRjVU9jam9pVnRjMFlzWjkyeHM0dGJ1?= =?utf-8?B?UXFma0poa3h2S0pDL0ZZMGxuVThZOXVpbzd1ZTVGa0g5OXBFMDBoNUhxTnl0?= =?utf-8?B?ZEdpTmp1SWR1WjU0QmQ0U3hNVnlTQlU4Q0pyVHAzdGdCdU1sQi9wRHc3NVFN?= =?utf-8?B?Q0t2eXFicms4V2xPQkI2OFhsNTZ5R3l0TVNWc3hOV2ZZK0E4SW95SGpwZnp0?= =?utf-8?B?VzZ4T3JjZUk2aWxNWDh0Tk9TVElvR0t0dmE0TFFZbzJNZndLOGhGbmR3R0ln?= =?utf-8?B?eDl6T1Z3MS9POSt5UTltZ3c2SS9zN3dzYmlyeUlQQzhYMkU0QXRTMGdENTZN?= =?utf-8?B?aUZYTG9iNm1YcGhGZlB0UkZ2NjFseDBOajNBVWxhU0ptYkVjTnkvSlhOOXpT?= =?utf-8?B?ZE9UNzkyUWFrYXZNYllnb3BBWTBUdndUb0MweG9CSCtyZHNObkF5bEd6bW1z?= =?utf-8?B?TzBYZkNXdHBWTXRnTllHbURqWWtTSFJWV3NTRDRpRmJOQ0FpbXFxaVdvUFlE?= =?utf-8?B?dGJrTDVBQ1I0MzA4endpTjVvSW1wV0FuTEhSWUg3WHBsSi9lekxFVkxqQkJ5?= =?utf-8?B?YVZGZmNGVmlNTy96WGU0OWtmdFB3RkwyVXMwaTBYWDhKNVVSb2pCMlZpOW5v?= =?utf-8?B?Qmt5dHNpWTlDTEVwNEc0VDJjSjN6VmxJUjk2TXBkYVlDOHVQZ3o4R2hYamIz?= =?utf-8?B?SlVGcVViUkpyRHhjbGFTc2VnbHNPSWVQSDQ5TUVUVFltaGhXelhieDN0aWsr?= =?utf-8?B?Q09UM2FyaFFvbTV0b3FsYjVLSDcrWjlURllUTFg2bWVJejZ1M0JJNUI3TWs2?= =?utf-8?B?VExFRzZSY1BLRkVVNnJoN2ZTZEVvQStXRFRFZ2t6QzZXY04ya3E2UzlXSUpT?= =?utf-8?B?ZmFqeVJ6clBGRDhHdE9UMXRhVHlxb0Zrd3BLdk1jb1pXanA4Mk5tSldrV1Bk?= =?utf-8?B?Z1M1enNWT1c3TW5hQllVTHYwRmdxOEhlWVRlaGpCQ2ZNLzNCRW1aeEFqSXU0?= =?utf-8?B?cGxQdmFldmlHV2NlMHo0aWxDNDZLd2Z1ZC9Ccy91bHhRcGNWNm9pcExaRC81?= =?utf-8?B?c0dXYUpJaVIvajRuNUNaaTdlaE0zemNmb1VlQXVSRnZoZVU3TDNUOXRhSXJj?= =?utf-8?B?bVU5SjUrcUdjaU1rbWk4WTEybytadk1pK3AyRE4zK254cGZNQlB3dz09?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 873120e3-073a-47f5-603a-08da389fab94 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2022 07:26:05.7961 (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: 6qaA8AhZAC4coqUX4v570SQV4otHheZaqxJF6hXaJmczFf7ZEj3ANoH7Gr7gM67BMkWKUyMziydH/NnAUW5xVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0401MB2268 X-Spam-Status: No, score=-3032.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, 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: Wed, 18 May 2022 07:27:11 -0000 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... > > >> 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 >