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

[H.J. Lu]

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?


-- 
H.J.