From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2042.outbound.protection.outlook.com [40.107.6.42]) by sourceware.org (Postfix) with ESMTPS id 320C43858D37 for ; Thu, 1 Dec 2022 07:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 320C43858D37 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=HraW/gLERU+RjfvlRGHs5qFjaWeeHArfS26L/ztvjzJ8agODX3Tro8PnsvcI2UM0KyvHF62j2jK3cHPcRzo6n9M1BgQY7rgtkLK4tgbksWQ3rZzDBruDvcd1KNzpFw2GmgmUgzgQXqUOzSTLBExhF9W635TF+JJiR6K9QcPvlT8RvdN2PVbSyirKf3DKXk3Zqby4MitLLqT67LRa4xfA/6BHyGChDSDKyjwZNvL7wICV6PUFIWjyahNrM6islzmO9XJPj2g8SpQP4QIc5U2s4w27/44hulvv6JKfsqaTOAFWJ0ITXFAsz/bqQtjuw+MfPIcSXU4LYvFsnI8jNuB35Q== 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=eAW4CbMNjWXtabHUfzlBuZc584zUQoStjd3TdIkdVv0=; b=f6S+Bc9i7G6Sp+CxelunGK7BBp2du+jDC+ccMdFBtRlWR6nwJCcJwm8rPhDbklLp3815hmf8IKBxdoXUrTvUD+yUEmp6LNH2F06EpTHo/qzOqWrKZgbqlvVoT66UYdcXQ00wOG/so2B2D+pSZNqpibqfOnJc2XV0ttwHGTo7ixWhdpOOr+sFqtJ07Bl5Z6JhDmFSqY6UpbJ3bf5BdZnpni6P7DKtvUMdXvaXEoCPi+hSavN0rTDNnQbwp6p6h/RUimpkJTwXYnnG/HkKfw/guO+ckqza81rXybTuH8Ir2bycs1hJuMApppd+RxOT7XWQspm19fo9pr2GD1BVDrk/7Q== 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=eAW4CbMNjWXtabHUfzlBuZc584zUQoStjd3TdIkdVv0=; b=EmxXl2bjv8x6Yf6+XD4cS4D1w9O6kKlWpJ5t7xzoc8mnwucvP2CHB6X1heDvjmcer8+OXXkXB62BuEif1Pd/P3zqTfPcIZ0N2mk9NlH09QhvMIdHVo1FkY8VwuGcF2dCsi3v57ydk90meeQmc0Tuew5EBLypmE816HHS/HSRysXnJnpYafPa13l2p3PPYA8A29I1KNdt0/E8l3uVLsHDyWlks9xHIdVk2sgIx/YC8lIEIPL+/8W54equaAkg1TF6xl0PyAXmwrN6h53IzjtncqhY/42mhSAd7ZN902JMDVKCLNT4QY23m3vle1b5V5w6NgQvSy13aWOpGioiDaw2Tg== 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 DBBPR04MB7660.eurprd04.prod.outlook.com (2603:10a6:10:20f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.20; Thu, 1 Dec 2022 07:41:30 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::4da2:ea8b:e71e:b8d8]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::4da2:ea8b:e71e:b8d8%4]) with mapi id 15.20.5857.023; Thu, 1 Dec 2022 07:41:30 +0000 Message-ID: <8bb7a0f0-5809-af64-7fc8-1aabe1047dc0@suse.com> Date: Thu, 1 Dec 2022 08:41:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2] x86: Remove libopcodes dependency Content-Language: en-US To: "H.J. Lu" Cc: Binutils References: <20221122181927.251937-1-hjl.tools@gmail.com> <6a5d4918-919a-8b6b-822b-17ce38488629@suse.com> <63e51eee-e9f4-5332-d69e-feca3421553b@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0123.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9d::16) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|DBBPR04MB7660:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f308a1c-cfc4-4252-1e80-08dad36f75d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JQX2r7ZKwbX7BN3eqztLfF1DDueDz1HLV1jhwEUCxMx7YP2NGPe+sKzuTdUv1hBgut4nVkUtgkHSaAYDLiY2OKRcKf51m8joXgqvynvx8mmjA1meMl+Wxo00GHgS0gLjFyawVjSBsdQX8BOVrKIbZBTfSD0IBtvRC0qBzKeOTB0Y+smgPqD+jtFkh13qosFWeJcIUuLUEDmWApFu+ABqODep8Bz4qsY0M0wBeYjMEOqu2TOXl2/N4PKBoLUElfyyVKuOZVclRpcRlAhHoJndq/Iz56iyaW1P1DsVGXvT8KWsUVmKGwQmd8wKMaJb9dDIePjrfhfvXsj8mWnUXSHRkQSkGBlrNBPmLDzH5+zl8L7UxqIAdLKlIeDd59gw6UBC1BsM+zBTyFa8t8Fo6p7x+68wQXYhXz0Y9W40sb8aC8+cWSTanKG3uodFZIXVIxPTY9RqFniqeTlZmHHIYgR7/3Qw7gPqunmZTzfJWQ/NQWVQT4DoXiyacJBX0EyZirh5+7AaY2eFQiyzOCUIPG3wk1POqGERdk9ctrsdItibj23CxjS6HGiTiAqd0i1Z2BFckOsSl9DQlYin6tYiKWtVqNaG2whRrPBd0T1dPn1gs1JevjDA23ZwtwlR5DtgGHkBGpLmWreC1nLwdGiV7svAbqQFpUeH7sUbxnzY0goNpQm+g68gEKDITTKgG8kVdAmCbQL0SPw92utffG0LhtY4rIKeCO5J9ewHSEgO752HDcM= 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:(13230022)(39860400002)(396003)(346002)(376002)(136003)(366004)(451199015)(316002)(478600001)(2906002)(36756003)(6486002)(26005)(83380400001)(53546011)(38100700002)(2616005)(86362001)(6512007)(31696002)(6506007)(186003)(66946007)(6916009)(5660300002)(8676002)(41300700001)(8936002)(66556008)(66476007)(4326008)(31686004)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N04vcExCazkvYWF3WS9oRnkvaVlySDNFVmpoY2hhZmZGREdPdEp2bGN1U2tY?= =?utf-8?B?RWNqT1drTUN1YndReG5TQlk3NVdPSVJyQU5LY21uaEl1MXgyak5xOWN6eGJ0?= =?utf-8?B?Z2RqZHNxVW43NS9oOHZKaUxGMGp5UXkrOG51c01NcFJ6SjltbkluQzErZkFn?= =?utf-8?B?L1N3QXJkZFU1OUtEMzlHVUdybzVVaG5hdVFUUkc5L3BRcDFKbFJmeUlrZk51?= =?utf-8?B?K0Q1ZWRpaDUwUVViRC9zTnlwNTVvREt1dVZMY2xFTHVLVmRvMUxSaGQ2T05m?= =?utf-8?B?aUtUY3BsdzE3aW91Yy93YW1RM1lKdE9ualovaUlkTTg0a0xyam5BQk1WMHlp?= =?utf-8?B?eW9ncjV2elFFWENJVmdGOXkwaklhRTdsS3VIRkVVcmpBeVlrcGJMMkJkSkI2?= =?utf-8?B?SWVhaDdvV3dUVStiakJUT1ZhVmZ2aUxvY2FhWmVrVTU1VnJzWmtMY2hZWGpX?= =?utf-8?B?OTlZTEw4aExIUHlMU1ZiSGVoUmNQdk5ETi9hVDU4aFlsR0xVdCtxT2k3d3p1?= =?utf-8?B?THZ1WUY3WThRQ0NxUmc4MHl5ZjY3MXQwaHNMM05SU2lqR1NqMDhLNXdUM0Z3?= =?utf-8?B?M2NHQTNuYm9vRlhzWklQVjFxTys0b0pnTG9jNHhIVnVXVUJoRnR0dDdpYnNO?= =?utf-8?B?OGpvUU5nQ0JZSjN6aUFSZWZpaGovRjlDdFdKLzNIS3p1SFMxZDY0ZktQS2VC?= =?utf-8?B?SUREUDFON3NXQ0R5VE53SDJmbUR4c1EzVTM4Y0lJWVI2cTBqbFhyLyt1d0pN?= =?utf-8?B?aEowaUp4WE1qQ0VUUzFIL1JLN1l1RFlldkxTK3kwRVdsUDBuRWxZOUEwRUg0?= =?utf-8?B?YU45VTVOT0xiNExoV0RSNTA1U0kxR2dWMHdSM0pMQ3N0V2E5cHJndVQza3Jr?= =?utf-8?B?ZStFamc2MHlSWmV5enFiMXoxOHM4bnZLZVFzbHMrRUZwRnA4SWIzZWxwTkRx?= =?utf-8?B?SG9pNWpDOFlvb0Z1ZXQxT2NNMXdHN3RwMmNrb1Y4SjdNYnJ2YzQ1VEYvbnhq?= =?utf-8?B?S3dUOTF4eU1QdGVoU21mMVI4VTc1TDVpdVJVRWdJNUF6a1R5SGNKS0VUWFZ3?= =?utf-8?B?N09aU3hrZzZSc1JROHNYaHVlR3VhUy9lMUs0M0tBZzQzM01DeG40SEdxQTJD?= =?utf-8?B?c1BlekhLbFN2ekRWYUUvTWtiSmRUaWFJOUhwUXJRdmYyVUFjamg2aktmMVhW?= =?utf-8?B?M3dMb3VxWnYwMlltMEZrSW10ZTFvbWIwSDUzSGkwZjYwSXZrdktvWW1yTFZu?= =?utf-8?B?YVRnWU9laERoYWk3TGRjNEllelZHWmJLTldFTm82dXhnL3lJSWpmaHVMUlVI?= =?utf-8?B?UmZxTXEvbXdCd0RDNHZkVGdsZjRaRk9LWlJGQ29OQ2xnWXVCdzRWU1U5cFNB?= =?utf-8?B?MUtzMU1uTDA4VXAyU3d1ZWZnNXpVNFZScjg3ZENsUy82M0hjKzZlVUlmT3ha?= =?utf-8?B?elM4OHNyRDJXU1Qrb2FqMmZLSHhtSHQwdGdqN3NMVnc1MVR6enBnQUlYNVp2?= =?utf-8?B?Vlg4U3ZFbnFyMEdFSDN1aUZwaTFrN0llYThiVlgxSEhFQTJta2pPSjhZcXV4?= =?utf-8?B?SkVNRlNTakhnSFVRRTh5ZkFlZ3dFeEJIbGprZWV3MWEzZkVld2Q4S1Z0MlNO?= =?utf-8?B?QW0vMGRkSGRiMjlDY3VFaWQwQlFFeDJjcWxmUjVDL3VmdmxwcGNPbHJiWUtn?= =?utf-8?B?TXhTRU1oOS9mSDg1UWI1elFiTU5iOUNzMnpTdVczb3FYRm9vUmtWZm9ZMmhn?= =?utf-8?B?S3hsNTYxS1hUdS9keGgyUHVXaVlIYTFuZmVpWXlFaDAxeW5vejRwQzk5UlZD?= =?utf-8?B?aGhaZmZJVkN0RDRjYzBGSjJkWjVVS0FTV2hJQnA5KzM0bGhzMG4xdk84Rzcw?= =?utf-8?B?OGthWG1obHE0VmhWZjhGQ0FFZitYWHk5K3dMWTFSQkN5SVVLemU1RytDZlpY?= =?utf-8?B?SjJzczBCTFZ3YnFITnJXMFM4ejNPVUJkZlVMelpqQjhzd1dMVmFEZFRIbU5i?= =?utf-8?B?TVZPbVc0SlJtTmZGRlAzNzZDc3RWZVA4VFRLaEJTaFZDV1pMMWt1K3hzQ2Iv?= =?utf-8?B?bnNDbUdoZlZLUkdKRXVGcE50UHowUFF4TS92YjhiM1pjUkJ6NkVzcUg2MGZs?= =?utf-8?Q?7P279bZVpeADFZ51I3usTpda/?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f308a1c-cfc4-4252-1e80-08dad36f75d1 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2022 07:41:29.9222 (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: yTt0+QC5OjYeWRjRjN+xeGI+fI5MgNox2sUQo978CErnkgE6qPbWQOi/NhWuYn3q2zFOqtYjY5Q3T4gvM7iFWg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR04MB7660 X-Spam-Status: No, score=-3029.2 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 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 30.11.2022 23:22, H.J. Lu wrote: > On Tue, Nov 29, 2022 at 10:58 PM Jan Beulich wrote: >> On 30.11.2022 01:06, H.J. Lu wrote: >>> On Tue, Nov 29, 2022 at 11:38 AM H.J. Lu wrote: >>>> On Tue, Nov 29, 2022 at 1:22 AM Jan Beulich wrote: >>>>> On 29.11.2022 00:49, H.J. Lu wrote: >>>>>> On Thu, Nov 24, 2022 at 2:19 AM Jan Beulich wrote: >>>>>>> On 22.11.2022 19:19, H.J. Lu wrote: >>>>>>>> --- a/gas/Makefile.am >>>>>>>> +++ b/gas/Makefile.am >>>>>>>> @@ -446,6 +446,12 @@ development.exp: $(BFDDIR)/development.sh >>>>>>>> $(EGREP) "(development|experimental)=" $(BFDDIR)/development.sh \ >>>>>>>> | $(AWK) -F= '{ print "set " $$1 " " $$2 }' > $@ >>>>>>>> >>>>>>>> +$(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: \ >>>>>>>> + @MAINT@ $(srcdir)/../opcodes/i386-opc.tbl \ >>>>>>>> + $(srcdir)/../opcodes/i386-reg.tbl \ >>>>>>>> + $(srcdir)/../opcodes/i386-opc.h >>>>>>>> + cd ../opcodes; make gen-i386-tbl >>>>>>> >>>>>>> I've made a patch to gas/Makefile.am as you have requested in reply to >>>>>>> my series. I will want to put that through some more testing, so I will >>>>>>> submit a v3 of that only a little later (and of course only unless you >>>>>>> submit a v2 of your patch earlier that I would also end up being okay >>>>>>> with). In the course of doing so I noticed a few more issues with your >>>>>>> change: >>>>>>> >>>>>>> For one I don't think you can put @MAINT@ on a continued line, as the >>>>>>> line continuation might then be hidden when @MAINT@ expands to #. The >>>>>>> list of dependencies wants expressing via a variable, which would then >>>>>>> be used immediately after @MAINT@ without any line continuation >>>>>>> following. >>>>>> >>>>>> Fixed. >>>>> >>>>> No, the same problem is still there. You either need to use a very long >>>>> line, or you need to introduce a variable holding the list of prereqs, >>>>> like I've done in my series. >>>> >>>> I got >>>> >>>> $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: >>>> $(srcdir)/../opcodes/i386-opc.tbl \ >>>> $(srcdir)/../opcodes/i386-reg.tbl \ >>>> $(srcdir)/../opcodes/i386-opc.h \ >>>> $(srcdir)/../opcodes/i386-gen.c >>>> $(MAKE) -C ../opcodes gen-i386-tbl >>>> >>>> and >>>> >>>> $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: # >>>> $(srcdir)/../opcodes/i386-opc.tbl \ >>>> $(srcdir)/../opcodes/i386-reg.tbl \ >>>> $(srcdir)/../opcodes/i386-opc.h \ >>>> $(srcdir)/../opcodes/i386-gen.c >>>> $(MAKE) -C ../opcodes gen-i386-tbl >>>> >>>> I didn't run into any problems. >>>> >>>>>>> And then your rule / dependency won't be enough on a "maintainer-clean" >>>>>>> tree, i.e. when the generated headers aren't there at all, and when >>>>>>> config/.deps/tc-i386.Po is still empty. In that case nothing would >>>>>>> trigger their generation; an explicit dependency of config/tc-i386.o on >>>>>>> these headers needs adding here. >>>>>> >>>>>> Fixed. >>>>>> >>>>>>> Finally you're missing a dependency of the generated headers on >>>>>>> i386-gen.c. >>>>>> >>>>>> They have a dependency on i386-gen which depends on i386-gen.c. >>>>> >>>>> In opcodes/, yes, but talk was about the rule in gas/. Yet despite >>>>> your comment above I see that you've added the missing dependency. >>>>> >>>>>> Here is the v2 patch. >>>>> >>>>> As said in reply to v1 - my objection to this particular use of make >>>>> recursion remains. >>>> >>>> The gen-i386-tbl rule doesn't touch any files used by libopcodes. >>> >>> There are >>> >>> bfd/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) >>> $$local_target) \ >>> binutils/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) >>> $$local_target) \ >>> gas/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) >>> $$local_target) \ >> >> I'm glad you spotted this yourself - I was just about to point out >> that my concern isn't only a theoretical one, because of the >> generated makefiles we use. You don't draw any conclusion though: >> Are you willing to accept my approach, specifically reworked to >> account for an extra request of yours? Or are you meaning to make >> another attempt yourself, avoiding the undue make recursion? >> > > Calling $(MAKE) in Makefile is very normal in binutils-gdb. Any further examples where this isn't done strictly top-down, or in a properly controlled way within a single directory? I can indeed spot many instances of $(MAKE), but none matching the pattern you intend to introduce. > I don't see anything wrong with my approach. I prefer my > approach. I understand you prefer it, but given you've found what's wrong yourself, I'm puzzled by "I don't see anything wrong with my approach". Or wait - looks like I misread what you pointed out above: That looks to be something from the top level Makefile. Yet then again I can't spot any such in my build trees. Where is that excerpt from? (I can spot somewhat similar patterns, but they're used strictly to recurse _down_, just like looks to be the case with what you've quoted.) In any event, a practical manifestation of the issue I've said I'm concerned of is this: If a 2nd party anywhere in the tree did the same you do, and if the two $(MAKE) invocations then raced with one another, then it's plain undefined what would happen to the recursed-into Makefile when that needs re-generating for whatever reason. Hence $(MAKE) recursion should only occur strictly top-down, with (suitably controlled) recursion _within_ a directory possibly being okay (would need proving for every individual instance). Jan