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

[H.J. Lu]

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.



H.J.

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