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

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.

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

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