[PATCH] i386: Check invalid (%dx) usage
H.J. Lu
hjl.tools@gmail.com
Thu Nov 10 17:22:35 GMT 2022
On Wed, Nov 9, 2022 at 11:21 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.11.2022 21:24, H.J. Lu wrote:
> > On Tue, Nov 8, 2022 at 11:21 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 08.11.2022 22:06, H.J. Lu wrote:
> >>> On Mon, Nov 7, 2022 at 11:34 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 07.11.2022 20:58, H.J. Lu wrote:
> >>>>> On Mon, Nov 7, 2022 at 3:44 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>> x86: restrict use of (%dx)
> >>>>>>
> >>>>>> PR gas/29751
> >>>>>> The AT&T mode special case operand (%dx) is valid to use only with
> >>>>>> instructions nominally expecting %dx to specify an I/O port address.
> >>>>>> Prefix the respective checking with an opcode check. Keep that as
> >>>>>> simple as possible by recognizing that opcodes 0x64 and 0x66 (which
> >>>>>
> >>>>> Since current_templates doesn't point to the matched instruction,
> >>>>> checking current_templates looks like abuse. I don't think error
> >>>>> messages should be a concern here.
> >>>>
> >>>> We use current_templates in similar ways in quite a number of places,
> >>>> when match_templates() hasn't run yet.
> >>>
> >>> Since the first template isn't the selected one, your check allows
> >>> the invalid opcodes.
> >>
> >> I guess I don't understand, but I guess I'll also give up. Which
> >
> > Your proposed change does
> >
> > current_templates->start->base_opcode | 0x8a) == 0xee
> >
> > to allow opcode 0xe4 and (%dx) is allowed for non-I/O opcodes.
>
> 0xe4 is very much an I/O opcode, merely one not allowing for (%dx).
But it also matches other opcodes.
> This solely is to ...
>
> >> template the check is done against doesn't really matter here, as
> >> long as it's one with the correct mnemonic. We could of course
> >> also re-order templates to have ones allowing for %dx first, but
> >> I view any such ordering dependencies as fragile.
> >>
> >
> > That is true.
>
> ... avoid introducing yet another ordering dependency.
>
> Jan
--
H.J.
More information about the Binutils
mailing list