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

[Jan Beulich]

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).

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
> 
>