From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20618.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::618]) by sourceware.org (Postfix) with ESMTPS id 3D0043858C78 for ; Thu, 16 Mar 2023 10:35:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D0043858C78 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MfPBoll6Ba2dPhwfGthtOALn06p+knT9pZIEyW6nDBO6KJfIoqbXPWyB4abOajfCJQ3+1XfoDoa1O6Nw2xG0RaB/j9uMZypOlpGkR82y665Oz4Ca8iT/uHoFgA8Di5vpFEIubeGaUfF5m0jXOo1Q6FCE8cBGnKv6YnwP3XOw9F4epw8/w6nvBA8lAsJDg5iTHtBUGS7ohInJJ7Eo5kc3O2WZ6d0mBGqYci2Qq8QHkpvNwsRcum1SoCaRd/l7aOQHjjbSCp6Vecql7aiormHFywUsDFErYZiyA4I+ZNLaj776sBMhGfZIO8YBQiUHqVwmBwT5thSKFAgNcO3jWexG5Q== 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=ZQ6m7yc+WiQImfr1wW3PkxC0uXitJLdoiujGot4OR44=; b=imZ9f2fkJA2U+POzrbCU0MTLDbDZi2cPiM45h0xM5Zv010wqlNUPhkMmFnLGUn3HMpQM0qmpQFRs6xC1MfJRgtrlEdgv2VhaQr0sTWtpK3CTfxpfAHxjhe/cUPCUlIedfZcSSjK9LPA0PPGgsovo4q9pETsl3IyW7ptE+4seDWogzirqCLWXFzCWV7FXra+XJJUulkMWG8rhww7V7ctd1bACd1WKscrrIn4UgH+IZ9pQthsHQMP4uwfLRH8mu9vUUi9w3dN9pE/+mErEEheUvWMeSi9gtOW+DasPshv3PSxcOxGPi5mDicUye05+lMOIMQEnkc8/rRha8+ZEge7kRA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZQ6m7yc+WiQImfr1wW3PkxC0uXitJLdoiujGot4OR44=; b=ffbwE9QM+UsqZJRNLP6Te0zf390Qf+OV0CBM2r0L9GCxHR4yx8itnenoc+YfIhFezRLxnNsGQ0f6Wsk8vjQWRToiA/oINclqk/hf3r83KnXXBenMAiump8tRu/GnuLiDmsTnei0GEuCNIMSOmnrUcfZ3G5RSeGVxYz9ktZ0MIHaW4jpVFFEUYypyhRYSit2LbMuwwgA6fmMlDEjuumS+KQwgqD4ozh1xKOcfiqEsucCruuxhfmQtOAJnje7s4pWja3Sfoxo4dhZjYYXphkBqkpi1XGcKAcGuF3ix7CqwSXt4gWPuTOdgKniiQo4DBkUdMC+AcM8tJcvQWcDkM5VETg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) by PAXPR04MB8319.eurprd04.prod.outlook.com (2603:10a6:102:1c3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.31; Thu, 16 Mar 2023 10:35:18 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::154e:166d:ec25:531b]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::154e:166d:ec25:531b%5]) with mapi id 15.20.6178.026; Thu, 16 Mar 2023 10:35:17 +0000 Message-ID: <8401f20e-2233-8135-1ac2-4b9475fab1c2@suse.com> Date: Thu, 16 Mar 2023 11:35:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH RFC] RISC-V: alter the special character used in FAKE_LABEL_NAME Content-Language: en-US To: Palmer Dabbelt Cc: binutils@sourceware.org, Andrew Waterman , Jim Wilson , nelson@rivosinc.com References: From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0094.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9b::20) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|PAXPR04MB8319:EE_ X-MS-Office365-Filtering-Correlation-Id: f0f48f7f-6a3d-40db-9220-08db260a22c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xVmaPGLEfTV2phDoJRwmCVp3Vhp57iE+MxNx6XgWRAjOuHVHcLgJf1e3bXcHo0zickaqu6+hb4rd/dUDuMclvC6CODnSKlJpr5SNEGoB8g+goJ19FNZiARpx076cvYLHzEZqWPRukEpe2mGwDZJHSpGZvrY9NlaDBAcGCLdkuhbgu4NkZsP7KpyMc724Vfc61g0UDwhSjjBuO20RMaeu81ay0fhR+cOLPNjw5T68HLvbLvBsvyqxiOvJ8NpEQYThkz44qg5aJsSiyvq1qkmPW/iCEHeK5q61c8JOs1nVcngeIzNC9ZFCDDXa/3n3pzLkearNojfrgjWJYv3M9cyeXIOPqYTbxuDE4e+Fzr2zk99g6gC8+3SyoV8/lYAPvb3p4MbJgAtolfYPvk9PdoCHvJ5ousuqG+RSBGFdnL7wQLoeY4Rd/Ho1nTHvO5mA7OPki3TE5AdrnyUMoyw6kg3Yy2Lzc0srFdpPT3p2+NAd1uG2grxOPhfs7N0aUIcb8Yw5pLH7yAE+lPMxE8dQpM/BdqwYJUGwBAhDGDfw/ef3xfqSLjrS2Z+UiOQdmL+MWdq3g8g7A3pZzm68yae56FyWz/gWoohaGNB/k5m+M5vHmfGWpY4EMAPsAeu8PbX3xPfNerk6ShnC8Rqg/NIfVM1vNXavWwev+B9sZDx6Wi2Ce2oGrDxPT3D9gODHgtA3q8NsWuNcarlBHPiUN9R/rugq9jFnQkwnNrBA0jeoihAnX7U= 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:(13230025)(396003)(346002)(136003)(376002)(366004)(39860400002)(451199018)(66899018)(31686004)(4326008)(41300700001)(8936002)(5660300002)(2906002)(38100700002)(36756003)(31696002)(86362001)(478600001)(66476007)(8676002)(66556008)(6486002)(66946007)(6916009)(316002)(54906003)(83380400001)(6506007)(53546011)(6512007)(26005)(2616005)(186003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eU8wRlc1a3RXcG1CRllsM0YrRVBiQ2J0SkFoM2hDUmFweU9XVWZNOXM4N01m?= =?utf-8?B?blc5emFSOW1xUTBhbTNtMGdUUGc0cklrODViVld4Qjh5Q045Ny9pamlxUU9J?= =?utf-8?B?dzEwQm1GbkR2SHJRcHdUM0pQamI0SE4vZytRWjE3RThJcUVuQmZwYjB0azAy?= =?utf-8?B?V2JEakdkdy9lZXlyOVFMcmgzZnZFY3NDTW85YnUwZjZLS2NFOUtkRTRkZDBh?= =?utf-8?B?eVpkWnhjWkpNcFVxS2NsWmlBR2V1aHpmeFVNNkNQQy84akpJUktmSlBuRFpq?= =?utf-8?B?VStxMHVFQ1dZeVFTdFdXRlU1UW9sTTE3Szh6Vmlrajk5OGN4VEpvK29tbVRF?= =?utf-8?B?TTRvcHI4M2NoN0ZGSE9saHZWaVZBK21Ha1Rtd2c3REVOL3pzclVlL0wvNSs0?= =?utf-8?B?SDRGY0NXUTcxejJkMHRKcFNvV0ljTzdZUmkvUXlTYy9xYnorQm1CQVNLTjV3?= =?utf-8?B?blhFVzNYUXVDNUMxQzc0dW8xWHRtTjRFOU9PT3daczBOMEJmNE01djc4d2Y5?= =?utf-8?B?MDFMb2VyWmJBQkxTQy84SmNVM3BIWmJzOGlLU2JHbjdXeHlPR0JlZW9VTWli?= =?utf-8?B?QVBuQ2ZMWjJ2bDlBejhDVWk5a1dFQUI4alU1ZFpJUC9wbHBGdGZqNjJCRG1I?= =?utf-8?B?TUo4SnN4anN4Nm1PeElLRXhtQzhUUlZGZ1orOStUVkhzMVZjMnZ3Tk50cFFz?= =?utf-8?B?blNScTM5bE56NWo3Zk9OWk04SDhYVzdxc3lzb0RSalhrVkt0Tm52a2xWQ0Iz?= =?utf-8?B?VWR4YXd6VE4vTDJsOVJmN0JMcE55Z2hKTmNoTWt4MWYveFVPQStybjdKeWxO?= =?utf-8?B?d3BGNGlzUkN4eHdMd0JaOTQraHpGWHlCV29QNmJxaDBOM1E1ZENFTHpscUo4?= =?utf-8?B?TmZZYW1aYWU1SmV4a3QzNUpvMGVzdk5uR3MyWVBIbXBDcWMyT1NEa3djRTdj?= =?utf-8?B?NjA5bDBSa21ua1FCNnVPbWl3dmY4ZmZpeFJkbTkvRDRTNEJTc2NFb0F0dGFo?= =?utf-8?B?dUJ6bVI3TGlwWUdKSktJL1UyMGJqMEVsZ25Fc0hGamVUNG9TNjdNRUd4bWQv?= =?utf-8?B?QTlpSlF0NGhmeTNUeThhbFMxTm5FVTllUEk2dURWeU1Sc1JCV1hSWHRyS2ZD?= =?utf-8?B?UDQxR3doaXNUZzZpVzdsd2xVZXdtK3JZTHYwajZzT1JXdVZadUppOWNUblFn?= =?utf-8?B?QmdJNmFWVDUrdGFOb2RoUzRUSUdPeHYySlc4emhINE1SOVJDRlFiQUtkMlQ2?= =?utf-8?B?SGtLOEEyazVZa1hvSHRKK0pKRTMwajhFSUU5VTBOZWFzU3dUL1E5Z0FDTllv?= =?utf-8?B?K1FDTWo0Rk0zOFZObktxSllOU1ZDbHNVS2pvZW41dUw2aVU2TzQvVkh6OWli?= =?utf-8?B?VzllL0lrOHpKU0IydUpqbjNQQnlJVzNEUm1aRVA0c3J0U2NIaXhreGNuYTht?= =?utf-8?B?N0hRUlF3NkQyODhFMWd2bjcxR2Flb0tWL0xSdmlOelRHK2phb1k0T3M3WHgr?= =?utf-8?B?YzlHazQ5VFZwYkF0RkNkcS9QUXZKcFRIUlNLZ3VQNDRYYmNpRnk3TFlLbFBv?= =?utf-8?B?RlF6WG1nMWJLZXc1SjcwNVowcndvZ2g1MldqSVFMK2M2YzltbGhISkkrSDZK?= =?utf-8?B?SitscXdxa0F1Wk40TG5LK2orblR6eTVSTTJoV1B2ZEk3bFZzNUJpZi9HeVhj?= =?utf-8?B?WkJ3WnlTQXFFdlFXQzh1UGJGTnJuU1huYndNbE9WaWtPUk1HNEV2RjluaGxs?= =?utf-8?B?YW1vZmM5L2ZDTmtNeXZlV1pYWnlXYktiMzJIcFlMQVIrVDRhSCtwOUdwTlUv?= =?utf-8?B?LzcrVk1PRXNNVkZ1V3hCcldOTEFab0t3dnc3dDhYaXFUWUZUYkNSS0dZRkow?= =?utf-8?B?dWVFRWIyRXByZHRWODd6TjNUa3FLODUzT2djYjhNTjBIa2E2V2VaK3R1eTRa?= =?utf-8?B?czVRZ1lJY1NLQWNHMU82TE1iU2J2OUNqelh2Q2NVYmd2c29wTTJONUtndVo0?= =?utf-8?B?Tm9tYjR1YXR6ZjZ3aWt2dFB6ZWZJZVZxRVJ1TjFOTW5Vcm11dkEzL1ErSzla?= =?utf-8?B?ZDZBWlI3d1FTSW95S3MzVXpwM2plQXBvTVIyY1BOdmNEQUFwVzZiKzYwL2Ns?= =?utf-8?Q?r+awvBzO2VAmIRph5aHt/mRHr?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0f48f7f-6a3d-40db-9220-08db260a22c7 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2023 10:35:17.9027 (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: qXVreoYZxfCFORLuUKF6LqRgPQJv80aXkQq5ZhcmQ4cFqeskzlBmPxQlFjxtu5MH73N9RvamdVF5UMb3vNPMww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8319 X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 15.03.2023 17:05, Palmer Dabbelt wrote: > On Fri, 10 Mar 2023 01:36:31 PST (-0800), jbeulich@suse.com wrote: >> The use of a space char there collides with anything using temp_ilp(), >> i.e. at present at least with the special % operator available in >> alternate macro mode. Further uses of the function may appear at any >> time. This likely is a result of write.h's comment not properly >> spelling out all the constraints placed on the selection of the special >> character used. Then again RISC-V anyway violates a constraint which has >> been properly spelled out there: Such labels _do_ appear in assembler >> output. >> --- >> RFC: Of course this breaks interoperability between older gas / new >> objdump and vice versa. But I don't see a way to resolve the issue >> at hand without introducing such a discontinuity. To limit "damage" >> a little, riscv_symbol_is_valid() could of course be tought to also >> ignore old style fake label names. (Personally I view this tying of >> functionality between assembler and disassembler as problematic >> anyway.) Thoughts? > > This wouldn't be the first time we've made a change around here in > RISC-V land, see 2469b3c5844 ("Riscv ld-elf/stab failure and fake label > cleanup."). Unless I'm missing something we maintained compatibility > with the old binaries there, I'd prefer if we can do that here too. That commit didn't touch the binutils/ subtree at all, so "existing" binaries would no longer have had their "helper" symbols suppressed. And indeed current code is merely bool riscv_symbol_is_valid (asymbol * sym, struct disassemble_info * info ATTRIBUTE_UNUSED) { const char * name; if (sym == NULL) return false; name = bfd_asymbol_name (sym); return (strcmp (name, RISCV_FAKE_LABEL_NAME) != 0 && !riscv_elf_is_mapping_symbols (name)); } i.e. no check for the earlier used special name. Yet the RFC question is specifically to figure out whether riscv_symbol_is_valid() should also be adjusted (at which point I could of course go and make it recognize the earlier name as well as the one that is in use prior to the patch here. (The RFC question also extends in the other direction, as we can't really do anything about old objdump then no longer recognizing the new label name. But that again would be no different from the earlier discontinuity, afaict.) > That said... > >> I question the use of FAKE_LABEL_NAME in make_internal_label(). The >> comment in tc-riscv.h isn't correct anyway because of (at least) this >> use - the symbols generated there are never used for Dwarf. And them all >> being the same makes it rather hard to associate relocations resolved to >> symbol names (e.g. "objdump -dr" output) with the actual instance that's >> referenced. Their naming should imo rather follow the model of >> {fb,dollar}_label_name(). >> >> Considering the special casing of FAKE_LABEL_CHAR in read_symbol_name() >> and get_symbol_name() I wonder in how far LOCAL_LABEL_CHAR and/or >> DOLLAR_LABEL_CHAR don't also need recognizing there (and then also be >> marked in lex[] just like done here). I can't point out a specific case >> though where there could be a problem. >> >> The checking for *_LABEL_CHAR in S_IS_LOCAL() looks to collide with uses >> of these characters in quoted symbol names. > > ... if this is all broken anyway then I guess compatibility doesn't > matter that much? I've definately seen some oddness around here, but I > think it generally works. The latter two of these remarks were general observations while doing the work, the first of which Nick meanwhile has reassured me is not an issue. Dealing with the first remark above would (aiui) introduce another discontinuity, though, so dealing with both aspects at (about) the same time (i.e. at least within a single release cycle) might be best. Provided of course it is acceptable in the first place to change make_internal_label(). Jan