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

[Jan Beulich]

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.

Jan