From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 6C4F538582A1 for ; Thu, 28 Jul 2022 15:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C4F538582A1 Received: by mail-pl1-x629.google.com with SMTP id w7so2140484ply.12 for ; Thu, 28 Jul 2022 08:59:54 -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:cc; bh=vOU0wWB1lE21wlWRxheQ22VSjhfrWBDRueNpeGdAosE=; b=ra50hQfuqeKHDuzpcpkoDffYuqo8ppuootRl7W3kplWuwwWJZf9Qvi1Ilinn3igZiv gt9kL+1C1bXVgKirh6TVJw0Dk+Yv7CM4Do9u2wBSJrXY1OtYOxzGDjrte4W6/iqrhaOq qd30ueQwNRZOKBsesnbyhMusOqW0smnIvwBsnzwwwkurj5D7klJ/faczvV0vTX/dGgJE 29memRXIqgq/vJvH14zGyrBFANwibM6ttwaOgs659WyP/c25Kp/OWO7WrN++/dcTjaTC qCU6JJTBuRMLQi/B6+pIr7WS0A7mIRQ3lunUcAwJHB92i+uXOBZ/DD88wY/WuxBtbE3+ Xl4Q== X-Gm-Message-State: AJIora9ojcOEYRm9IRO+SbG9gsD3HVWPwduydL9S1/gAGY3h+KPZyJyP VtDJw1AQc9jIIZgkEjUAfVM4SzMAiTc1y2h59aXqg4lJ X-Google-Smtp-Source: AGRyM1veGaeKteoHobtr1iee9B4pwxGLE9EXGXK80B9ZUTpIHyZZr40tQ2DygCiTw8F4HGs8Ivld6PDbteRdyBeBmQg= X-Received: by 2002:a17:902:b215:b0:168:da4b:c925 with SMTP id t21-20020a170902b21500b00168da4bc925mr26113283plr.155.1659023993404; Thu, 28 Jul 2022 08:59:53 -0700 (PDT) MIME-Version: 1.0 References: <20200309121117.GM5384@bubble.grove.modra.org> <20200309130204.GN5384@bubble.grove.modra.org> <18e1e00a-7ddd-e5b3-6fb5-f452e9ee0f20@suse.com> In-Reply-To: <18e1e00a-7ddd-e5b3-6fb5-f452e9ee0f20@suse.com> From: "H.J. Lu" Date: Thu, 28 Jul 2022 08:59:17 -0700 Message-ID: Subject: Re: Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3019.0 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:59:56 -0000 On Thu, Jul 28, 2022 at 8:48 AM Jan Beulich wrote: > > On 28.07.2022 17:13, H.J. Lu wrote: > > 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. > > Thanks for digging out the discussion; I have to admit I had forgotten. > Do you have any opinion then how to restore proper diagnostics? Right > now I'm leaning towards doing the line splicing in i386-gen, using some > form of continuation character (or sequence) that we can expect > compilers to leave alone (initial thought: double backslashes). If you can find a better solution, let's use it. Thanks. > Jan > > > ---------- 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.