[PATCH 5/7] x86: re-work insn/suffix recognition

[H.J. Lu]

On Thu, Sep 29, 2022 at 9:06 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 29.09.2022 18:00, H.J. Lu wrote:
> > On Thu, Sep 29, 2022 at 1:08 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 28.09.2022 21:33, H.J. Lu wrote:
> >>> On Wed, Sep 28, 2022 at 5:49 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> I guess to prove (and going forward guarantee) the apparent behavior of
> >>>> parse_insn() I'd like to constify its first parameter. This might
> >>>> involve adding a cast (to drop const-ness again after the call), which
> >>>> I generally would like to avoid, or some "interesting" pointer
> >>>> arithmetic. If you have any opinion here up front, please let me know.
> >>>
> >>> Can we avoid it by adding some new entries to the opcode table?
> >>> I don't think we need many such entries.
> >>
> >> I'm afraid I don't see the connection between the intended constification
> >> and what entries there are (or not) in the opcode table. I view it as a
> >> desirable property of the function in the first place to express its
> >> behavior (of not altering the input string) by a pointer-to-const
> >> parameter. In fact I guess I would make such an adjustment a standalone
> >> (prereq for the larger change) patch.
> >>
> >
> > Rescan means that the first scan fails.  Can we add new entries which only
> > do the second scan?
>
> Why would we add such redundant entries? All that could happen is them
> going out of sync with their counterparts processable on the 1st pass.
> The overall goal has been to reduce redundancy and hence the risk of
> inconsistencies.
>

These new entries should be rare and only for existing instructions.  We won't
add more of them.

-- 
H.J.