From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by sourceware.org (Postfix) with ESMTPS id B08AA3858284 for ; Fri, 2 Dec 2022 17:19:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B08AA3858284 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc32.google.com with SMTP id q2-20020a4a3302000000b0049ee5fe3ab7so796825ooq.8 for ; Fri, 02 Dec 2022 09:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aplXPNouWZdNgPw2ldYETVpWS4VGbS5ZxCDg0hEH+Es=; b=qVk4NGeaGXulME0QNmPLAZ2nOEE0bnDTZxLP1iG31WFPxAAmVBwhiJTMjoPDvAj+RT JadZX6H119Psix8mFKV2tFUMm9XZZPlBzAcK9vB4woaTXoy7nDP6hjMQMZZJnvmuW5xx YHzTh2vhR7Ju/OHZeAxIaV5A27uFsyrH79hnM4nIpl+CQkB6Wc9Lp9qm5og8hi8n5D1l ftLkpKyYkiHpzSwq1BaL0sqrZsOqvsu2yjMVNYK32wYkGRSZF0xrqq9mxacvtQGeLF5l bOnLJKFof38ZjkfEp0bM1VcddSQmmWGffAGslIDtY7uMuMO3fLfbOszCMB4lODf4vf// nOaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aplXPNouWZdNgPw2ldYETVpWS4VGbS5ZxCDg0hEH+Es=; b=cRH+yWhyiRt9g5X2W/e4qxnfLBptDkbUdpacdhLNl6cdCmJ7CpRqkDS0AgmjAK6EXI QqvOaRzGUFs4Ijt3xrIqYtlZ2RyoWEvInM4lvMnISEndht6OW+nXooyK00qsMI1bWKUY SBrzVGnGuPWLBSj848tPKDujEszwuLwxW/ZQLpbSXLwqhxR33aU0EqraJnYcWvOObcUW ygnay2grLXjZXMvspf/UHFXWGmLFSEfqJTFU1XGajxwfNDTNnfaa+AIWiCiSy7AfZd+D 16rs+i47sOIhjltKQMywyEuU85VfUk7FKCJy0EkBUAO3p0J6mQlMN5YgHG8kgAwr6oOS nWUw== X-Gm-Message-State: ANoB5pl5Y42IHbgB/gEJFBbJ6imp/3dUBYRfsLKzreAen3lbjt4/AnJr ciPO0nuYsECZ1VZSZIxgjHjng5acRWiphrkhyMQ= X-Google-Smtp-Source: AA0mqf4nJzQGYtNSY2elUvoWdcwg0PPN6FHu5udu60zxuDi3UXj6X6sCXYjdv3PJmuAzsZxYH6pNHqfIQMPGMhTIq7M= X-Received: by 2002:a4a:dc9a:0:b0:4a0:5b89:cacd with SMTP id g26-20020a4adc9a000000b004a05b89cacdmr10323635oou.40.1670001576853; Fri, 02 Dec 2022 09:19:36 -0800 (PST) MIME-Version: 1.0 References: <20221122181927.251937-1-hjl.tools@gmail.com> <6a5d4918-919a-8b6b-822b-17ce38488629@suse.com> <63e51eee-e9f4-5332-d69e-feca3421553b@suse.com> <8bb7a0f0-5809-af64-7fc8-1aabe1047dc0@suse.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 2 Dec 2022 09:19:00 -0800 Message-ID: Subject: Re: [PATCH v3] x86: Remove libopcodes dependency To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 Thu, Dec 1, 2022 at 11:16 PM Jan Beulich wrote: > > On 01.12.2022 19:26, H.J. Lu wrote: > > On Thu, Dec 01, 2022 at 08:41:28AM +0100, Jan Beulich wrote: > >> 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 > > > > Fixed. > > In which way? You still ... > > > --- a/gas/Makefile.am > > +++ b/gas/Makefile.am > > @@ -448,6 +448,18 @@ development.exp: $(BFDDIR)/development.sh > > $(EGREP) "(development|experimental)=" $(BFDDIR)/development.sh \ > > | $(AWK) -F= '{ print "set " $$1 " " $$2 }' > $@ > > > > +config/tc-i386.@OBJEXT@: $(srcdir)/../opcodes/i386-init.h \ > > + $(srcdir)/../opcodes/i386-tbl.h > > + > > +# i386-gen will generate both headers in one go. Use a pattern rule to > > +# properly express this, with the inner dash ('-') arbitrarily chosen to > > +# be the stem. > > +$(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 \ > > + $(srcdir)/../opcodes/i386-gen.c > > + $(MAKE) -C ../opcodes gen-i386-tbl > > ... wrongly recurse from gas/ into opcodes/. In fact I can't spot any > change in regard to the cross-subdir operation that I continue to > object to. I'm afraid I'm unaware of ways to address this other than > by avoiding the recursive $(MAKE) invocation altogether. $(srcdir)/../opcodes/i386%init.h $(srcdir)/../opcodes/i386%tbl.h will invoke $(MAKE) only once. -- H.J.