From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 005C03858C54 for ; Wed, 30 Nov 2022 22:16:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 005C03858C54 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-oi1-x22c.google.com with SMTP id v13so135723oie.3 for ; Wed, 30 Nov 2022 14:16:29 -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=sseEVH/YHTPoKxnAhS5VoEKXK7ceGF8RwOd9M+cIvYs=; b=f9P3eV/fa+lD4U/qOSBeuEiY7+ZiQ3NAgX5YYMEXwgT2JHjomUBAgjz/UchRGMBGHa BRasXrSfjLR2pzIm0RHSJ9Q1Cwnkf8etNCsu5FpcgKkKB1rEQXuwYO2kFIWmq7vv1Wy0 8YxycSZM/zsV0swbiOwDKLPdRkfy0ThnTa5+7y+U83YoJj34pQzOylDoSfUS0YAbmXiI S62BKWx38m4QVi1bLkBD3uEihhniqgdOwXczK1w45Gp4cETPnlYiyeP+98WOvKJBkx5Z uiZ1dk4zEt05AjONPr/Y/FmK6G9GttH612CP3PBWrjZXw6lBk2ELKzsMtbKp+aZr/tSZ VeZA== 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=sseEVH/YHTPoKxnAhS5VoEKXK7ceGF8RwOd9M+cIvYs=; b=8A02EfU6wwX4VuMG1E3Uvj2CURC+G8Ha9coOy46itzE9a4tkjbS62ltglVNV5iOcVi bvm5fODGb232cFRwBkLnoslauWwEDoElaeDzioKvquVNQX01PCGiVKFU67cDEXZCJ3Nj vWtzQ47dPY+h63WS8zVTK8lCn5mj0jsDuM+tb4iNiADDFikNvMqjDjfwFSCBpJLKKL2/ uVzRyNzgLADeoik7ZjZUggqTEFe7B97IluLxPOrEtIcmVt5Y//3BuHGrGCGHnENGaf4J 0km+xF2Tgd9ACfd1YdgjSCU59LgXjEtyCfKehSw/wuMYScN+iLVdo4+H1VDLb945pS11 KyCw== X-Gm-Message-State: ANoB5pnVrkH+XrZ8wAYMgADkkVGH5rMnx8UPsD1qwin+tfi7FtcUJVLu X/LGbLr44qKwfFHijOKdKsBYzkigV+OIT42pjFM= X-Google-Smtp-Source: AA0mqf7OtW/k4GCQJI5ZAVHllFH8hjYNnlzRHHR1dZzjCL/W1wpBzTSTjXznxhtOIbLdjGHG7y9BZz+dLtu7eE5uqiM= X-Received: by 2002:a05:6808:22a0:b0:35b:c6c4:7a33 with SMTP id bo32-20020a05680822a000b0035bc6c47a33mr4246911oib.266.1669846589085; Wed, 30 Nov 2022 14:16:29 -0800 (PST) MIME-Version: 1.0 References: <20221122181927.251937-1-hjl.tools@gmail.com> <6a5d4918-919a-8b6b-822b-17ce38488629@suse.com> <3f038bc9-6188-9bc4-d73c-51cc633fd69d@suse.com> In-Reply-To: <3f038bc9-6188-9bc4-d73c-51cc633fd69d@suse.com> From: "H.J. Lu" Date: Wed, 30 Nov 2022 14:15:53 -0800 Message-ID: Subject: Re: [PATCH v2] x86: Remove libopcodes dependency To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.5 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 Tue, Nov 29, 2022 at 11:31 PM Jan Beulich wrote: > > On 29.11.2022 20:38, 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: > > Note the missing line continuation here. They are on the same line: $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: $(srcdir)/../opcodes/i386-opc.tbl \ or $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: # $(srcdir)/../opcodes/i386-opc.tbl \ > > $(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 have no idea what make makes of this standalone list of filenames. > Without the line continuation these wouldn't be dependencies of the > two named generated files. > > > 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 > > Again these aren't dependencies of the two named generated files. > > > I didn't run into any problems. > > I'm surprised. > > >> One further request at least for consideration: In my v3 I've moved > >> the inclusion of opcodes/i386-tbl.h quite a bit further down in > >> tc-i386.c, as I think it's preferable that way (not introducing the > >> static arrays earlier than necessary). > > > > Does it make any differences? > > It is simply more logical to introduce definitions (not just > declarations) not among the ordinary set of #include-s. And it keeps > related things closer together. > I prefer keeping "#include" together. -- H.J.