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

[H.J. Lu]

On Wed, Sep 28, 2022 at 5:49 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 27.09.2022 01:52, H.J. Lu wrote:
> > Sorry for the delay.  I was on vacation.  My main concern is to call
> > strdup and free for each instruction.   I prefer to add new entries to
> > deal with rare cases instead of penalizing all instructions.
>
> Hmm, I think I can take care of this concern: As it looks, at least
> parse_insn() leaves the input buffer undisturbed, so minimally I ought
> to be able to limit the strdup() to just a very small set of
> mnemonics. I'm not sure yet if I may even be able to avoid the copying
> altogether; I'll have to check quite carefully in particular
> parse_operands() and the functions it calls. But perhaps relying on
> this would be risky looking forward, so I guess we better don't make
> assumptions here and instead flag mnemonics (in the templates) where
> retrying may be necessary when no match was found during the 1st pass.

This sounds reasonable.

> FTAOD - I take it calling free() with a NULL argument is not a concern?

We can use free (NULL).

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


-- 
H.J.