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 2B9FA384781A for ; Fri, 18 Mar 2022 09:39:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B9FA384781A Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp2057.outbound.protection.outlook.com [104.47.1.57]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id de-mta-15-mwQbqtTWMquIuvs7tHWz1Q-1; Fri, 18 Mar 2022 10:39:47 +0100 X-MC-Unique: mwQbqtTWMquIuvs7tHWz1Q-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eyNrtCPDrKVX+lP2eVBPl0ZM1w/uXvvi2kK5426r6lOfuHJmpiXQv85bgx5M7zDI+dNr+YIS0gUpCV1/+VGZj5YV/sqCXFhI3LUfZOaDUpASyHTNDVaS5c1RLIIO/37iXNZCws0+LaVFtY2YkhOZmB9yqs+XQRlgSq6dYKZTpoMn9/1ysn8uwxyeQ4XnOwbRLOG4Xu+IKVqrahO2e+knR3E90M7HbyyTEc95omuHfHKd/03STgH1NGWLV8dakKvYYfYp/pVOWbIiV7hxqzC+a8ojVNnaciLrU/3LaYaYkW7WYkLZdEeMGJa8sL4oy1mXtr1YKmBmceUrTOFk1WZIHA== 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=5VdKxiJzM7quwMEuibHhan5pO1Bt9l414vOPNkwP7O8=; b=M48NAFmawRriLQ0DzQtwHbe+chR8ibBAvz44OjYcO7yg4RbrN7eabYKbFWBnTDvYSmyg2JWAg2Mvl3MGZ/Qz8DLwNIdvsbT8jt4mIWzZp+Uf+l072v6/8gyMfv4fEC1w2QkGLrQYp/e3VZWliZRfT4MyTvnE5+hKNYmcgJsmHhsti+BpjGLKVGbk38T8XzA5fKB9Halocfin8CSloH6TkBfKdStJfQ4WrqoV30iSjaPXIEzcwMtiOyWuD0/GA0WzMPsYdOk2rgJ0qltDZTDtmAGZH3/vgp+fE0EKh70iTH8xbJ15EIr7z8mT54Izw40iIBGaolDL2QAnyOLHBtYsbg== 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 AM6PR04MB5607.eurprd04.prod.outlook.com (2603:10a6:20b:a5::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.17; Fri, 18 Mar 2022 09:39:44 +0000 Received: from DU2PR04MB8616.eurprd04.prod.outlook.com ([fe80::2d79:4387:3887:ef9d]) by DU2PR04MB8616.eurprd04.prod.outlook.com ([fe80::2d79:4387:3887:ef9d%9]) with mapi id 15.20.5081.018; Fri, 18 Mar 2022 09:39:44 +0000 Message-ID: <2614e201-d2a0-6e68-23f7-ea4c14700df0@suse.com> Date: Fri, 18 Mar 2022 10:39:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: PR28977 tc-i386.c internal error in parse_register Content-Language: en-US To: Alan Modra CC: binutils@sourceware.org References: <2da05d25-9304-bb71-1fee-9370a0171331@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: AM6P191CA0009.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::22) 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: 06d5e2d5-79d5-40f9-4962-08da08c33c11 X-MS-TrafficTypeDiagnostic: AM6PR04MB5607: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: Vyn0gvJofewKi/Ga9O3DRJ8QunRodEV/kwuGdugBTJVhGM4p1GqVbi1S8AGytfbZfxanNY38JIo6xOEHGmhFFb3rHLkrzlmVow3tFPFqBpOx7zB1NPoA+fxLwrPLouDfkiPAy/Bc0AX8uG1sLLnpz3peq9RdFqsKaSnaXAXh35q+gZ6FWHwv0qvxnp3Za8qWOR6Wo8hKmPgxq7ms777RehQae5ylD59TnFDR4ZacYi88qXepmts3UWgBy+MnnYHtXZznVVGonCcJvkZYZ6iYHQJpHzb9zqsn5H3W+kXb+u0FDASCfNHtRkpFw+U6zFVYn2pPmCSHKjw0r8kyjNeg0tD/AaBozwUgtqxy2zmKFfWGdmIfgmZcRH97nhLyaUJfb7GVWqt2f91Yggr/Q3T2p4ypsqO3sUpwVSSkkGNbh3J93pf6SV6cnbwR67ty0wf3io242j/7FO3KCqacsXFlPLGcKvPMyqGwFVHMY1LzKXwBnmXNE8kiaUiqaWVO7WV1d2pd+gsAlqTQvz9eL8PcqsCtTV+PtwgF74DrQrmoKF5r2uhtz/hhcjbHqJqISejPTIODu6TqwCRduOVfFs1C/Mcf7gVdvUhs5clS3cxuVWjCvkbIifv1s1OZMUBoT1btI1qEHobVqyjgYUH+/Iqwxc/B3pI6J5+Y82AJTRLldVvqA8vEu6PZaczacrjZUi8erbPkM390ULTqBmPAUssmpy3mRs73UhUf9pvHVCWO9r8= 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)(508600001)(6486002)(316002)(6916009)(31696002)(38100700002)(86362001)(2616005)(26005)(186003)(53546011)(6512007)(6506007)(36756003)(8676002)(66476007)(66556008)(2906002)(66946007)(8936002)(5660300002)(4326008)(31686004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?l+5/FDherqSkEAX9OEu1+u/iVK1xyvInPVmPphV6VSMdurqQ4x/01PsRTOEn?= =?us-ascii?Q?clQhODF5PReq0Wj8zZp4I36X/EKlg4aNxeN5bbEHwhe1rXr2octkGB5eUvhT?= =?us-ascii?Q?GI29sgAp9q1B7VzP5bJ9Iccd/t8UNNsJ2OidjP422eC6n99ClkuVghyIvBnn?= =?us-ascii?Q?/GOtZiKVYFvpXjjlnp6o5ka4ummBRcAHoV3f7EmURA/5pbbBuTKhN+1raSBF?= =?us-ascii?Q?z5z83Dw3NwpqYZj5ZoXCYowY/LCN3TYENYOGMKKGPb6A6g9L5t/7r1XtK/o6?= =?us-ascii?Q?u6rgc5Oa9DJTbHMH+aKVR0yEw/BKtiEx/a1BwTmT/z9ebXgqlSxk4LUqqEmz?= =?us-ascii?Q?+CzssZNrwJLQbTu4/3VNpIqwUwlzRauCJTZV1VrhfEToqdL0/nvfffV93biH?= =?us-ascii?Q?g5YLFBd9/mT8vB95pdYUjYCAA3l0P/uIco15sNa3JZ1JfNLgoQTnS1uSI3Oa?= =?us-ascii?Q?KAGRBkxSOS4BScMuT7Y7DWJbBKv6m+BEAZPqNWsU0zf/Cwje7fPqMk9XFpz7?= =?us-ascii?Q?/dSw2Lx4Dpz7cCPJcUqWfcI5UTEZ8y3PQH0qsZZ3LD7fx7HyQOP/WrYAGnGY?= =?us-ascii?Q?2VUVGK86Z5YVgcsThUZ45PDyhIHwSvRJnWmTx0sAFSWRUGjVNirsq0mWdYJY?= =?us-ascii?Q?q1przZZwwrQ/E5B9m6n6ECxQNisv0Z7hcOKQJ1WFfr5uPeGWHrTlbwqiCXWz?= =?us-ascii?Q?e81KUcU5QSZnLcLOfqUjtvQkl8zNytCNlPLvNJGJZgyOaG0Tu3FuHNVMQ0mo?= =?us-ascii?Q?uLnTH7cd9gX/GvaH8DsgCcBCLfnLQV//oPeYM2T4/ySRBY9WdM0CQJupnfqL?= =?us-ascii?Q?VebbQ36WR6ZzxYEj7JMy4TI+qLkBwpOjvg8E43lq6Br5yL2BNmCTN8nDMTfl?= =?us-ascii?Q?/ELy2cMNaBuKt4SU9KscLneFrt3saz8M8QVHQ7HPRgCdqM4mucD8T8535Bi6?= =?us-ascii?Q?ePHTN0dQPT0HnCQT32A5m+NqQ65G3uiZOYWMHLNzylc9mlEJEBHoFTMc2Bwf?= =?us-ascii?Q?jLGwsR0Wgzt4P5bbpgVY/KEguXDTxtLrG25WsQVGfRWplvkZrsbQs2MTkG6i?= =?us-ascii?Q?rvjI9zMCsltNCfJZZhwSo4Mqyye5aedlL9TMZw+OVPvUXa5TwBakUawaTIxy?= =?us-ascii?Q?MXoTju7Grb2rUdiThagdKU5oF10veHgbBqVbIlF7poYgVxOhZaQM9hW219Tc?= =?us-ascii?Q?3OXlkj/pAOT0CejQyVCER77bfSqvejEMuDDmYRF1JW2paRnE5hxDswWQ/6yW?= =?us-ascii?Q?lxIWCwz+7VcwtXhB2FSQhaI8q7n0twlVX4SqmaCcAdANyBqdMU3Q5Vxoz7Uw?= =?us-ascii?Q?Y5/DZbEzzZUUPMso58owmLdTkrYcWVpyiJK2z503CpEVbNKpU/sj/q1mRjXV?= =?us-ascii?Q?Mk+wacLvrB55GclJnT2g6AUoJmmeA1R2Rrv9cPU+GcnEfo9boIZQ5crpd1Bo?= =?us-ascii?Q?uMnnoqz0tGOsCZ18erIfXOPaZrcHjxso?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06d5e2d5-79d5-40f9-4962-08da08c33c11 X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8616.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2022 09:39:44.6694 (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: UTE+a5kM3XnpKsbqa06klvJxjQ7VErstO1NRpc2dmLWEAftshpyai5eDx6oY6bj1JZA7Css9c0WWiMAVMlvzUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR04MB5607 X-Spam-Status: No, score=-3029.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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: Fri, 18 Mar 2022 09:39:50 -0000 On 18.03.2022 08:32, Alan Modra wrote: > On Fri, Mar 18, 2022 at 08:12:46AM +0100, Jan Beulich wrote: >> On 18.03.2022 07:56, Alan Modra via Binutils wrote: >>> PR 28977 >>> * config/tc-i386.c (parse_register): Handle X_op not O_register >>> as for a non-reg_section symbol. Simplify array bounds check. >> >> Hmm, isn't it that ... >> >>> --- a/gas/config/tc-i386.c >>> +++ b/gas/config/tc-i386.c >>> @@ -12952,17 +12952,18 @@ parse_register (char *reg_string, char **end_= op) >>> { >> >> ... the if() right outside of context here is pointing at the actual >> problem? Why would "s=3D%rdx % %rcx" result in a reg_section expression? >> Imo this clearly ought to be expr_section. >=20 > Perhaps, but we are off in the weeds anyway. >=20 > The original fuzzer input had a completely crazy expression for "s". > s=3D%ymm5%%%!%%%%!%%%%%%%=1D%%%%%%%%%%%%%%=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%%%%%%%%%%!%ebp%%%%%%%%%%%%%%%%%%M%%%%%%[s<=EF=BF=BD=EF=BF=BD%[s<=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%%=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD/+=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%[s= <=EF=BF=BD=EF=BF=BD%[s<=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%'%%= %%%%%%%%%%%%%%;%%%%%%!%%%%!%%%%%%%%%%%%%#NO >=20 > My testcase was a little tidier but still gives: >=20 > mad.s: Error: invalid operands (*GAS `reg' section* and *GAS `reg' sectio= n* sections) for `%' when setting `s' That's only with your change in place, I assume? I'm not seeing this with your change not in place (i.e. on a slightly older tree I'm working with). > The aim of the patch is to stop an abort *before* we decide the > expression is invalid. i386 parse_register was being called via > md_parse_name in gas/expr.c:operand. It still feels like your change is merely hiding a problem elsewhere. Going from your example (and observing where the abort actually is reported) I added a 3rd instance of x=3Ds. Then the abort continues to be reported on the 2nd instance. If things were working consistently, I would expect it to happen either on the first instance or at the end of the file (in this latter case the location reported would simply be bogus). I think the original know(e->X_op =3D=3D O_register) was actually quite appropriate when seeing a reg_section symbol come in. No reg_section symbols violating this should ever be constructed, at least not for x86. There might be architectures where such makes sense, albeit code like this in expr.c: else if (mode !=3D expr_defer && segment =3D=3D reg_section) { expressionP->X_op =3D O_register; expressionP->X_add_number =3D S_GET_VALUE (symbolP); } makes me think such should never be put into existence. I seem to have a vague recollection of, very long ago, having discussed with you already the question of too little use of expr_section in the course of expression evaluation (without any actual outcome as far as changes to the code). Jan