* Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl [not found] ` <fa409167-5838-8e27-ab21-b1c1f4231912@suse.com> @ 2022-07-28 15:13 ` H.J. Lu 2022-07-28 15:48 ` Jan Beulich 0 siblings, 1 reply; 3+ messages in thread From: H.J. Lu @ 2022-07-28 15:13 UTC (permalink / raw) To: Binutils, Jan Beulich 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl 2022-07-28 15:13 ` Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl H.J. Lu @ 2022-07-28 15:48 ` Jan Beulich 2022-07-28 15:59 ` H.J. Lu 0 siblings, 1 reply; 3+ messages in thread From: Jan Beulich @ 2022-07-28 15:48 UTC (permalink / raw) To: H.J. Lu; +Cc: Binutils 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 > > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl 2022-07-28 15:48 ` Jan Beulich @ 2022-07-28 15:59 ` H.J. Lu 0 siblings, 0 replies; 3+ messages in thread From: H.J. Lu @ 2022-07-28 15:59 UTC (permalink / raw) To: Jan Beulich; +Cc: Binutils 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-07-28 15:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200309121117.GM5384@bubble.grove.modra.org>
[not found] ` <ed204381-01c8-635c-b63a-dce7cde6dee5@suse.com>
[not found] ` <20200309130204.GN5384@bubble.grove.modra.org>
[not found] ` <ee2989ba-3cae-836e-a942-8732d3ebdba2@suse.com>
[not found] ` <CAMe9rOre-vOMXXUD87yQb0hmcD-19obNiRPxEqJvbmsaWUY+5w@mail.gmail.com>
[not found] ` <d18c178d-e8df-5b82-d83e-3b34792b56c9@suse.com>
[not found] ` <CAMe9rOpdVUZ_bj=-fFRmuruS3rjgQo4V4k2TyDRSBkQO7MBM-A@mail.gmail.com>
[not found] ` <CAMe9rOpy7q77=aECOc_eXWMh1qzV7cX1ZVRR5+vjr3k0CCke5g@mail.gmail.com>
[not found] ` <fa409167-5838-8e27-ab21-b1c1f4231912@suse.com>
2022-07-28 15:13 ` Fwd: [PATCH] x86: Also pass -P to $(CPP) when processing i386-opc.tbl H.J. Lu
2022-07-28 15:48 ` Jan Beulich
2022-07-28 15:59 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).