Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl

[H.J. Lu]

On Thu, Jul 28, 2022 at 8:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 28.07.2022 17:13, H.J. Lu wrote:
> > Here is the background info on
> >
> > commit 384f368958f2a5bb083660e58e5f8a010e6ad429
> > Author: H.J. Lu <hjl.tools@gmail.com>
> > 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 <jbeulich@suse.com>
> > 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 <hjl.tools@gmail.com>
> > Cc: Alan Modra <amodra@gmail.com>
> >
> >
> > On 09.03.2020 16:30, H.J. Lu wrote:
> >> On Mon, Mar 9, 2020 at 8:09 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>>
> >>> On Mon, Mar 9, 2020 at 6:57 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 09.03.2020 14:48, H.J. Lu wrote:
> >>>>> On Mon, Mar 9, 2020 at 6:41 AM Jan Beulich <jbeulich@suse.com> 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:
> >>>>>>>
> >>>>>>> <cc:opc, o:0, no:1, b:2, c:2, nae:2, nb:3, nc:3, ae:3, e:4, z:4, ne:5, nz:5, be:6, na:6, nbe:7, a:7,
> >>>>>>>          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.