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.109.102]) by sourceware.org (Postfix) with ESMTPS id 70DD93856DC6 for ; Tue, 3 May 2022 13:26:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70DD93856DC6 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2051.outbound.protection.outlook.com [104.47.12.51]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id de-mta-31-IbG4p1P-NEOouIL9ylVV-A-1; Tue, 03 May 2022 15:26:31 +0200 X-MC-Unique: IbG4p1P-NEOouIL9ylVV-A-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gQ1Wb2kXbwc6Di3CI1WqXqw7V6/xtD1YLQfFH82YeFF/tCOMWpiTwmzLR5q8WrOUYQPYsNgPXnHp5LGgGhzOeAIMBZby2yzvfaEIw8L0ElfgZ7t/xbdIv5CJnPd83Ae7p5xk8cg+dUpzFvcXwW1bVcKPiOyClpVt6h8meloSvSeS68zCp7z0TTNUCErNnDnl5LF2WmH+GfvRmKMbzKD9mQbGTXmWpoKM5G5eGHb/6vKD2Q627LerRZJwXcwA5pSkG+MN9vAt5G8ulC5//9fXr6jxmstjZD3urxaHQeUipFJ8lgXelUH9FFbVJjXjxiXscGElNEGwDO9lScK7IoqvGg== 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=6D5xX5q7/E/HBnJwlymegV12emxLBW0loufa3Q8Zr6o=; b=HvjhxRoVU55Ragz4y3EoFfHPPd8+nmGbRfm5xDuodKQJgDEDTdI9dmNqxNnjWExl2np3MlyXioIlM1AWaElZfNliXteCIU0JC7MBaeinpuz9VPncfzQiiWjEZzaQEkscwmpKX2wWUDP7l/bcTmbINOho1FUv7NSP56JeghxFsrDmFLQ/dLuiZMvNnE2UnurLhpxxih7VQe2xXpMDEEOYF8mPSr7awn3EAhV+swGDvk476vllwZ24irbVxxlo3WH7YG3QhB6ge6+iO4ccMAVjYRwjrfxY7HrjddBeptJxD88fIjFanfz4H/GYajkSrwn/+JpeD+8CAEoKX4gm8zEhWg== 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 DU2PR04MB8616.eurprd04.prod.outlook.com (2603:10a6:10:2db::16) by AM6PR04MB4952.eurprd04.prod.outlook.com (2603:10a6:20b:7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24; Tue, 3 May 2022 13:26:30 +0000 Received: from DU2PR04MB8616.eurprd04.prod.outlook.com ([fe80::5cb0:5195:4203:7c2f]) by DU2PR04MB8616.eurprd04.prod.outlook.com ([fe80::5cb0:5195:4203:7c2f%8]) with mapi id 15.20.5206.013; Tue, 3 May 2022 13:26:29 +0000 Message-ID: Date: Tue, 3 May 2022 15:26:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 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> From: Jan Beulich In-Reply-To: <84567b31-7ed1-a377-7d05-8b6596871ae7@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AS9P251CA0014.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:50f::18) To DU2PR04MB8616.eurprd04.prod.outlook.com (2603:10a6:10:2db::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0362c6c8-ce64-48fb-e5fe-08da2d088869 X-MS-TrafficTypeDiagnostic: AM6PR04MB4952: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: rpca5oE/Rh0fEsxp5bFtJ8uQguIWZF/m6TUSOILKN8uLMa5nUxv6Ryaa25D/lGVC8fuqJPYCDU1eUU8QzuBxbi/ufas0U5ZDS+1c3AQkZe5WCmfo7ja+9bAdo1fjS5L6glJJa+DJ7gmTINZeHcEPBLhopSEsu/kKQv2+PzjwA5Ix/mFk/OdKUd2gc3sCKAkvV8qmEOhqsSVGCGQw834i2sVKEkQ/4/AZE3U7bEdsHCNp4N7hLipSfH4zofuL+C09Zr26QSczkpAR0ecaVSbmGhmuiqIMz0vuDxIhRP1SlbzZvCB6NfCIHl/dlolFX9kXI5r+ZorSi9hEtlBToOLMZPB8zRVtxToQkdNWvheUcQ4S0WDgYb6wSOscw+lGt5RdA2C/FlsaiEd/8LbTgHxsi8I2Cw4RMVkJABw5WXmGxnbhzPPt4Ejx6W65qqiPrVFmxWqT6T96v+nNeoYTkIhH06gM/64nkD5FeQnlCwwQFyIeEcYwlbKDY7rigVA9wefD5g+3MpA0xjWGhBeeziynAz1sr6euv15sCD6pnvvZ5f2YYDda5gLVLyx0rgd4BO7ZHnXsnZIOFPRhvlrDFNA9NFDvonnaOb+1jVOq4YpwT4F4pDMRvtTgY6ICkUmMYYIjpO7NZ83GqIADVx4SXj9WrVwnstUwiOwygUsOABic2nx558+nncaOmSjHSrqI42YlTqFb8r+wjqtLkZvEkr7U7voSHSRz0wTXveJ/qgmePxV/3naR1pa14yZKzNFVUuc1WqcHTMYgllgrlljqVyUTEg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2PR04MB8616.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(2616005)(6512007)(83380400001)(508600001)(6506007)(6486002)(26005)(186003)(5660300002)(8936002)(36756003)(31686004)(2906002)(66556008)(6916009)(316002)(8676002)(66476007)(66946007)(53546011)(38100700002)(31696002)(86362001)(4326008)(132733001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TDVzN0MwcnprUFlHZVJ4dVYrQStJd3ptbm96UFNCKzdnMXlodWFNNHJMK3kv?= =?utf-8?B?aEFHcnlHVXBHS3gyRlF4SmUxcVpEbFY1ZTFYdkdkU0xjZ2hrOWlkNGVSaUFn?= =?utf-8?B?ZGFabytWOEF0a2JKblhtbytLVzRwOXpwYjllMnRqZlVtZExkVWw1RmpISVB2?= =?utf-8?B?VGxpOUZ6VmVmRjBIaTJpdGdhY0QyNmRjKzArak4ycS9iSVVrSmlBR3NFQWdJ?= =?utf-8?B?ZTFaaFJiVUtXRjZGY0YvbGZySnBjdnJZMTcvSUl0NFlFRElDOGo4VzNncUZo?= =?utf-8?B?Sm9UbjFFdzI0Sm9sQ0RwcHVTZU43RGRBYUV6RVVCR1o1dnY2ZUpKN1h2a1Ax?= =?utf-8?B?THhrazJGMnN5OW5VdE1FYVp5czF0NVZZcUtlL1RKTFhETDVzN3VVT1RRZUlW?= =?utf-8?B?eFhaZ0svdUlDWjFMekJLQXY0c2pNK1VsNkJsdk5RQXNDcFg3VFJJWUk5QWE5?= =?utf-8?B?Ykl1T0tOS0M1aVY1SWJNZ1JJRVFqamgwZ2lzOStIZmw2c0k0d1VxbzJwZ3dh?= =?utf-8?B?UzlHUlY3Q0JkYkZDb0Z2aVdTTWVqczZFM2Q5am5sMnlXWGdoME1sVTNtRUt6?= =?utf-8?B?VjcwOWQ4TUVRcGdnekdzM0JqVlVtVHl3NlNNVVV1M045NHFJTTd2Wm1SZk9C?= =?utf-8?B?VEo3VVpDbGpaZWpzS2NFcllEWEZYRmp5QTZHdWpTdnFqdEhmWGRXL1ZOSTdG?= =?utf-8?B?RFh6Z0tMWStVVU5zV3NOYmVWalpvaXJkam1idDdCTlBkck5Md3h6azhKWk5U?= =?utf-8?B?QmZjSmpZNFF4Y2dvSmJKV0E1bGtHeDJRTHpWVUZaQ20wZjhwa0syNCt0RHFv?= =?utf-8?B?SmQ1cUpyc3lXdTkvVWpsRDhkYnp2eURET0JBT2tqOTVOcDl1NmIvWlFOQ09x?= =?utf-8?B?NjdBVHp4M0RrUmV0cm5yWWZ4MTNTT1dGQkJvK2ViNEMxc1czL3FyUUlxU3ds?= =?utf-8?B?NVJMMU1vWWJCelgyR3d1cDdOWWVSR3ZuQnNEdDNFQWpmT1lEQ0ptaW5RTmFS?= =?utf-8?B?YWpYMHFjUXdhUEcreHR0b0FUTThUci90QkJiSmxuWVJEejF1LzExNjJKcjdO?= =?utf-8?B?N3dDeTFMOTkwZmlDc3VZNXh3TWQ3aS9nODB5VmNiMVFTQUpZVDZiQXptZWE4?= =?utf-8?B?akFtVnA0SUZrdUlQcjNUODJIMEpuUXpMZ05xRkttMjhIV1ZCY0xadnc0YWNS?= =?utf-8?B?bnVGN3JxZnhDWlBPQzZyTHBnckptb09BNjFYNElCK3lPOEF3YUFDUTRUSHRT?= =?utf-8?B?T0U5U0I3QTRUdUR5RTdlQ3lZT1R2eVZhWXh1WG1NaldUSlNkR1NzMVVPYWh3?= =?utf-8?B?UmZ1ZXp3clNDTXdGNnlvbGR4S29MZ1FTcWNmRnl3dUgwNllpVFI3S2ZKZHNJ?= =?utf-8?B?MzFuR0lDc2VVSENvelhZZ1B2Nkw5MjFKVlNyTS9jcGl5cytlUlRzVm0xQU15?= =?utf-8?B?cWtoZnhPbnBBRkJPTUNENkRQRGJ6OTNVSzZ1UFhuNitWcjBEc0lCclBGNG5O?= =?utf-8?B?c0d1NGUvdUp3bkw1d1N5a1NPSEpnZjRxS1FNYlhsV1pvcmFyVWZJQ3FqL1NJ?= =?utf-8?B?M2tlR3ZtMXRJalo4cTh1ODkzRS9YVVU3eFFxeUdtQTZJZFcrNjhuUVpYNTdP?= =?utf-8?B?T0xBRHZWMWNITVB3bGJxOU5ONW8yQ0QrVVJQT1VYbDlNWTBRdHpjbjF3VzNM?= =?utf-8?B?QURtMkhMWFMyS2FGWW1PZTdjUjFIS1FxOEFHakN6RDBIOGVlOS9zcmFrRUVD?= =?utf-8?B?YlFBVndxMnNYOG0wTVJMWXZwSW9vU2dlemFYbFExNGVhS2tZNFZUWVZ4aGZJ?= =?utf-8?B?Y0gyZWk1MC94dmQ2WXZrZmdNRXRWalhycHpoNGQ4dXA3SldiUjVzNWNtTUdi?= =?utf-8?B?RnB0U2t3bmhRZzk0QjlyUVhqaURYWU11NUFuZWptbEhkdCtCOWo1UzhHbUw4?= =?utf-8?B?ekJhK3gxLzNWTStoM1VCUllTWjdqWHN5N3hmUldVYnBwTTF3cFZRK3BMWXZH?= =?utf-8?B?WWdXN3JScDA3RmRlWmptMjREWEgyWGVGZDdrM3JpZjYzTFN2SkkraFpyZ2pR?= =?utf-8?B?cnRTTllackN5ZGpiR1NzNUxWWUJ1a1VYU1Y3UDFXWTg0Sko4SVl1SDE0MXlZ?= =?utf-8?B?WW5JaVU2dDlXeVFoUXY5Z21XQXdNUkVDTStEczF6RW1TYlRaYWxZdlVmNENy?= =?utf-8?B?cFg1QW8xbTdZL0V0S0Z6eFJwNDV4YmFTNkNXVGFvUURpY3pjUDBhcThPTitI?= =?utf-8?B?Skt0b0JQTm42WUNBMWNwbUx0aDlmaUE0NW1tLzBSSHBYWUtYRytQVUhMSmF6?= =?utf-8?B?RzM4UlBoQVpJa3M2alcwRkl6V1paK2RwZHRtcnVmUEdlQTdOUlNRQT09?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0362c6c8-ce64-48fb-e5fe-08da2d088869 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8616.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2022 13:26:29.9236 (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: IS2nxjMbKVO6ue4UY8ltCgt+f77aLCMFlKcMIkNAKVe753WRuDmont5squrPQqpOYwS4Mkfgaf4ctMwd9vTuew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR04MB4952 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 03 May 2022 13:26:35 -0000 On 14.02.2022 14:35, Nick Clifton wrote: >> According to my observations other insns aren't affected, >> yet the change to parse_adrp() doesn't really stand out in said commit. >> Hence I'm neither really certain that's the one, nor how a possible fix >> could look like. Do you have any thoughts? > > Well the change added a new argument to the ...get_expression() function, > so all callers were updated. There was no specific intention to change > parse_adrp for some other reason. > > Anyway - this does look like a bug, First of all tc-spu.c has a comment precisely to this effect: deferred_expression() does not evaluate . at the point of use of the expression. But I think beyond the patch sent earlier today to fix some quirks of the original change, there's a more fundamental question: Was it really intented to reference the (equated) symbol in the relocations? There's now an inconsistency in that some relocations against constants reference the constants (when aarch64_get_expression()'s defer_resolution is false) while for the ones here and a few others it's the symbol which is referenced. I think one or the other ought to be used consistently, and judging from other targets (x86 for example) it _may_ be that it should be the constants (but it may also be that x86 is flawed [there are quite certainly also quirks there]; from a purely abstract pov I'd say the symbols ought to be used if they're global and constants ought to be used when the symbols aren't global, or are e.g. hidden). Some of my confusion with the original change is that, rather than doing more evaluation of the involved expression, you switched to doing less. This felt the wrong way round. I've come up with this (not cleaned up) alternative, which makes . uses work as expected while still taking care of the issue in the original bug report: --- 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. If, otoh, the symbol references in the relocs are indeed meant to be as they are now, 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. (Additionally the commented out lines cause "redefined symbol cannot be used on reloc", which I expect would go away as well when fully resolving the expressions.) The one argument speaking against resolving expressions right in aarch64_get_expression() is that symbol properties (global, hidden) aren't necessarily known until quite a bit later. So perhaps really a two-phase approach would be needed - aarch64_get_expression() to simply call expression(), but fixup processing then resolving the expressions as long as no global is involved. Which in turn doesn't feel like it should be arch-specific ... Jan > although I think that it might be > restricted to just an unadorned reference to dot. ie: > > adrp x0, . > 1: adrp x0, 1b > adrp x0, . - 8 > > When assembled and then dumped, gives: > > 0000000000000000 <.text>: > 0: 90000000 adrp x0, 0 <.text> > 0: R_AARCH64_ADR_PREL_PG_HI21 .text+0xc > 4: 90000000 adrp x0, 0 <.text> > 4: R_AARCH64_ADR_PREL_PG_HI21 .text+0x4 > 8: 90000000 adrp x0, 0 <.text> > 8: R_AARCH64_ADR_PREL_PG_HI21 .text+0x4 > > So the ". - 8" expression has evaluated correctly, but the "." expression > has not. Would you care to open a BZ for this ? > > Cheers > Nick >