From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 9FECB38582AB for ; Thu, 28 Jul 2022 15:14:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9FECB38582AB Received: by mail-pj1-x1030.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so2488500pjf.2 for ; Thu, 28 Jul 2022 08:14:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=t6rNMJFWKsOPBznm/7TZ1kkkt4SwstQMX5nN/OhISpY=; b=Era4oETGt3mYpA8xAMJ54SmVa73Cjlbxp41jLUW7u/wqy5qe4gzVl4HicJbWKmUZ4l xj5YwB++C6c9EaxjqrMCECgIIM3UM5ngv2JiIIgOMEcPneobYc62KdhaFdwOBqSv27DT /bL9x6FxPkjh2QIBO+mlc5LXYiV1RCsjThD1aLjRr1wMVFyx6mSCDiqf1ysUX+vqZpO5 V3NDadX+ME2TC1sZyhV4XRBmju0IzkqHFPUskk8ZLNWMkl05VX/qLfwL8reMTmPX1HB4 ucmMf7jvC0VfLGrH2F55h3W0vPhGZkhCWEEN8QxRHr7Nj82f1qZqWYx/PltQSzfTYt0G qQ3A== X-Gm-Message-State: AJIora9QmSSY1Ller4X3V+UfzZQu9s/Ow6HwiW1kM1W/YmKYLmT5etup SgYlQricpnrPSvONy080Z981YVkv3JCtcGtmhTNXjLsov4Y= X-Google-Smtp-Source: AGRyM1vso+DWPKK5lvJsc5UGJh4L9BdA//LS5aH9vUxllq2Jweqnv8+XrBLZ3aByV4NL/3s1ph2EZ25vIS5N9WTg66s= X-Received: by 2002:a17:90b:1e03:b0:1f2:518a:8f78 with SMTP id pg3-20020a17090b1e0300b001f2518a8f78mr10807029pjb.217.1659021270257; Thu, 28 Jul 2022 08:14:30 -0700 (PDT) MIME-Version: 1.0 References: <20200309121117.GM5384@bubble.grove.modra.org> <20200309130204.GN5384@bubble.grove.modra.org> In-Reply-To: From: "H.J. Lu" Date: Thu, 28 Jul 2022 08:13:54 -0700 Message-ID: Subject: Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl To: Binutils , Jan Beulich Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.1 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 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: Thu, 28 Jul 2022 15:14:34 -0000 Here is the background info on commit 384f368958f2a5bb083660e58e5f8a010e6ad429 Author: H.J. Lu Date: Mon Mar 9 08:23:46 2020 -0700 x86: Also pass -P to $(CPP) when processing i386-opc.tbl Since i386-opc.tbl contains '\' to avoid very long lines and i386-gen requires that each instruction must be in one line, also pass -P to $(CPP) to inhibit generation of linemarkers in the output from the preprocessor to support i386-gen. H.J. ---------- Forwarded message --------- From: Jan Beulich Date: Mon, Mar 9, 2020 at 9:01 AM Subject: Re: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl To: H.J. Lu Cc: Alan Modra On 09.03.2020 16:30, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 8:09 AM H.J. Lu wrote: >> >> On Mon, Mar 9, 2020 at 6:57 AM Jan Beulich wrote: >>> >>> On 09.03.2020 14:48, H.J. Lu wrote: >>>> On Mon, Mar 9, 2020 at 6:41 AM Jan Beulich wrote: >>>>> >>>>> On 09.03.2020 14:02, Alan Modra wrote: >>>>>> On Mon, Mar 09, 2020 at 01:20:10PM +0100, Jan Beulich wrote: >>>>>>> On 09.03.2020 13:11, Alan Modra wrote: >>>>>>>> My latest build (of git 865e20278c2) dies with >>>>>>>> gcc -E -DHAVE_CONFIG_H -I. -I/home/alan/src/binutils-virgin/opcodes -I. -I/home/alan/src/binutils-virgin/opcodes -I../bfd -I/home/alan/src/binutils-virgin/opcodes/../include -I/home/alan/src/binutils-virgin/opcodes/../bfd - \ >>>>>>>> < /home/alan/src/binutils-virgin/opcodes/i386-opc.tbl \ >>>>>>>> | ./i386-gen --srcdir /home/alan/src/binutils-virgin/opcodes >>>>>>>> ./i386-gen: error: i386-opc.tbl: 423: missing ',' or '>' >>>>>>>> >>>>>>>> Looks like the continuation backslashes are not accepted. >>>>>>>> >>>>>>>> I'm not particularly concerned, I fixed my local build just by editing >>>>>>>> i386-opc.tbl to remove the line continuations. Please fix when >>>>>>>> convenient. >>>>>>> >>>>>>> Hmm, I'm puzzled: Of course the whole thing built fine for me. >>>>>>> Line continuation characters should be gone after the pre- >>>>>>> processing step, aiui. >>>>>> >>>>>> Yes, they are. Leaving for example: >>>>>> >>>>>> >>>>> s:8, ns:9, p:a, pe:a, np:b, po:b, l:c, nge:c, nl:d, ge:d, le:e, ng:e, nle:f, g:f> >>>>>> >>>>>> ie. the lines are not joined. Which is a bit surprising. >>>>> >>>>> Actually I've now recalled that a while ago I had entered a >>>>> bug for this (86079), which got closed as invalid without >>>>> me really understanding the reasons, nor the reasons for why >>>>> the behavioral change was made (there's an indication there >>>>> towards producing better line number association, but I don't >>>>> view this as good enough a reason, as said there). >>>>> >>>>> H.J. - should we go with very long lines then, or should I >>>>> see about introducing an alternative line continuation >>>>> sequence that i386-gen then deals with internally? (I don't >>>>> suppose -P is standard enough a compiler command line option >>>>> that we could use it here alongside -E.) >>>> >>>> '-P' >>>> Inhibit generation of linemarkers in the output from the >>>> preprocessor. This might be useful when running the preprocessor >>>> on something that is not C code, and will be sent to a program >>>> which might be confused by the linemarkers. >>> >>> That's from gcc's doc, isn't it? By "standard enough" I meant >>> to also cover other compilers, as I didn't think binutils were >>> meant to be buildable with just gcc. >> >> Compiler needs to support -P only to process i386-opc.tbl, >> not to build binutils. >> >>>> Please use -P if it works. >>> >>> I'll work with gcc, but I'm unconvinced that'll be enough >>> coverage. >>> >> >> I will make the change. >> > > This is what I checked in. Thanks for taking care of this; let's hope no-one comes along wanting to build the opcode table with a compiler not treating -P as we expect it to be treated. Jan -- H.J.