public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Hu, Lin1" <lin1.hu@intel.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
	"Lu, Hongjiu" <hongjiu.lu@intel.com>
Subject: Re: [PATCH] Support Intel USER_MSR
Date: Wed, 25 Oct 2023 10:48:44 +0200	[thread overview]
Message-ID: <73e9aef8-802c-2df6-563d-787512e1f2ac@suse.com> (raw)
In-Reply-To: <SJ0PR11MB5940B107B703A713D5B1E7E9A6DEA@SJ0PR11MB5940.namprd11.prod.outlook.com>

On 25.10.2023 04:01, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, October 24, 2023 8:02 PM
>> To: Hu, Lin1 <lin1.hu@intel.com>
>> Cc: binutils@sourceware.org; Lu, Hongjiu <hongjiu.lu@intel.com>
>> Subject: Re: [PATCH] Support Intel USER_MSR
>>
>> On 24.10.2023 12:01, Hu, Lin1 wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Tuesday, October 24, 2023 4:56 PM
>>>>
>>>> On 24.10.2023 10:38, Hu, Lin1 wrote:
>>>>> I've thought of it so far is I can use a Fixup function like
>>>>>
>>>>> static bool
>>>>> uwrmsr_Fixup (instr_info *ins, int bytemode, int sizeflag) {
>>>>>     if (bytemode == d_mode)
>>>>>       {
>>>>>         if (OP_Skip_MODRM (ins, 0, sizeflag))
>>>>>           {
>>>>>             if (OP_I (ins, bytemode, sizeflag))
>>>>>               {
>>>>>                 ins->codep--;
>>>>>               }
>>>>>               return true;
>>>>>           }
>>>>>       }
>>>>>     return false;
>>>>> }
>>>>>
>>>>> Then the uwrmsr's unit will be { "uwrmsr",       {	{ uwrmsr_Fixup,
>> d_mode },
>>>> Rq }, 0 }.
>>>>> What‘s your opinion?
>>>>
>>>> Hmm, not very nice, but I can't exclude it simply won't get any better.
>>>> My desire was for there to not be any new fixup function, and for
>>>> OP_Skip_MODRM to be used directly in the table entry. (In any event,
>>>> if you really need to keep this new function, please combine the
>>>> three if()-s into a single one, helping readability quite a bit.
>>>>
>>>
>>> I have another idea, can I have a new function like
>>>
>>> OP_back_codep(...)
>>> {
>>> 	Ins->codep--;
>>> 	Return true;
>>> }
>>>
>>> So the uwrmsr's unit will be { "uwrmsr", { Skip_MODRM, Id, Back_Codep, Rq },
>> 0 }.
>>
>> Well, the main thing I dislike is the decrementing of codep, no matter where it's
>> put. In case you don't think you can get away without, I guess I'll try afterwards,
>> aiming at an incremental change then.
>>
> 
> I have another one in mind at the moment. Can I have a bool variable in instr_info,
> 
> @@ -221,6 +221,9 @@ struct instr_info
>    /* Record whether EVEX masking is used incorrectly.  */
>    bool illegal_masking;
> 
> +  /* Record whether the modrm byte has been skipped.  */
> +  bool has_skipped_modrm.
> +
>    unsigned char op_ad;
> 
> And the Skip mod/rm byte pattern will be 
> 
> @@ -11668,7 +11658,11 @@ OP_Skip_MODRM (instr_info *ins, int bytemode ATTRIBUTE_UNUSED,
> 
>    /* Skip mod/rm byte.  */
>    MODRM_CHECK;
> -  ins->codep++;
> +  if (!ins->has_skipped_modrm)
> +    {
> +      ins->codep++;
> +      ins->has_skipped_modrm = true;
> +    }
>    return true;
>  }
> .
> This change will be applied to all other similar sections (include OP_E).

Yes, that's along the lines of what I had in mind.

Jan

  reply	other threads:[~2023-10-25  8:48 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  7:24 Hu, Lin1
2023-10-16 12:11 ` Jan Beulich
2023-10-18  7:51   ` Hu, Lin1
2023-10-19  8:36     ` Jan Beulich
2023-10-24  8:38       ` Hu, Lin1
2023-10-24  8:55         ` Jan Beulich
2023-10-24 10:01           ` Hu, Lin1
2023-10-24 12:02             ` Jan Beulich
2023-10-25  2:01               ` Hu, Lin1
2023-10-25  8:48                 ` Jan Beulich [this message]
2023-10-25  9:11                   ` [PATCH][v3] " Hu, Lin1
2023-10-25 11:43                     ` Jan Beulich
2023-10-26  6:14                       ` Hu, Lin1
2023-10-26  6:21                       ` [PATCH][v4] " Hu, Lin1
2023-10-26  8:31                         ` Jan Beulich
2023-10-26  9:08                           ` Hu, Lin1
2023-10-26  9:25                             ` Jan Beulich
2023-10-26 10:26                               ` Hu, Lin1
2023-10-27  9:00                               ` [PATCH][v5] " Hu, Lin1
2023-10-27 13:36                                 ` Jan Beulich
2023-10-30  5:50                                   ` Hu, Lin1
2023-10-30  8:31                                     ` Jan Beulich
2023-10-31  1:43                                       ` Hu, Lin1
2023-10-31  2:14                                       ` [PATCH][v6] " Hu, Lin1
2023-10-31  8:03                                         ` Jan Beulich
2023-10-31  8:35                                           ` Hu, Lin1
2023-11-14  7:14                                         ` Jan Beulich
2023-11-15  3:09                                           ` Hu, Lin1
2023-11-15  3:34                                             ` Jiang, Haochen
2023-11-15  7:36                                               ` Jan Beulich
2023-11-15  7:41                                                 ` Jiang, Haochen
2023-11-15  7:48                                             ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73e9aef8-802c-2df6-563d-787512e1f2ac@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hongjiu.lu@intel.com \
    --cc=lin1.hu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).