<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 28, 2024, 2:11 PM Jan Beulich <<a href="mailto:jbeulich@suse.com">jbeulich@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27.06.2024 23:18, H.J. Lu wrote:<br>
> On Thu, Jun 27, 2024, 10:39 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br>
> <br>
>> On 27.06.2024 15:59, H.J. Lu wrote:<br>
>>> On Thu, Jun 27, 2024, 5:25 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br>
>>><br>
>>>> On 27.06.2024 08:06, Kong, Lingling wrote:<br>
>>>>>> --- a/gas/config/tc-i386.c<br>
>>>>>> +++ b/gas/config/tc-i386.c<br>
>>>>>> @@ -7137,7 +7137,8 @@ md_assemble (char *line)<br>
>>>>>>              && i.base_reg<br>
>>>>>>              && i.base_reg->reg_num == RegIP<br>
>>>>>>              && i.tm.operand_types[0].bitfield.class == Reg<br>
>>>>>> -            && i.tm.operand_types[2].bitfield.class == Reg)<br>
>>>>>> +            && (i.tm.operand_types[2].bitfield.class == Reg<br>
>>>>>> +                || (i.tm.operands == 2 && <a href="http://i.tm.opcode_modifier.nf" rel="noreferrer noreferrer" target="_blank">i.tm.opcode_modifier.nf</a>)))<br>
>>>>>>            /* Allow APX: add %reg1, foo@gottpoff(%rip), %reg2.  */<br>
>>>>>>            break;<br>
>>>><br>
>>>> What does the <a href="http://i.tm.opcode_modifier.nf" rel="noreferrer noreferrer" target="_blank">i.tm.opcode_modifier.nf</a> check achieve here? All EVexMap4<br>
>>>> ADD forms permit {nf}. The comment also needs updating, to avoid it<br>
>>>> going further stale (it already hasn't been quite accurate). With the<br>
>>>> comment properly updated to list all permissible forms, I think you'll<br>
>>>> also note that what you add to the condition is too lax: Aiui<br>
>>>><br>
>>>>         add %rax, foo@GOTTPOFF(%rip)<br>
>>>><br>
>>>> is not supposed to be permitted (according to the testsuite additions<br>
>>>> you make).<br>
>>>><br>
>>>> Finally a question perhaps more for H.J. than for you: Why is it that<br>
>>>> ADD is special-cased here for the APX EVEX-encoded case, when there's<br>
>>>> no similar special casing for legacy encodings?<br>
>>><br>
>>> ADD is the part of TLS sequence.<br>
>><br>
>> I expected you would say that, but it doesn't answer my question: Why a<br>
>> special case for EVEX-encoded ADD but not a special case for legacy<br>
>> encoded ADD/MOV (and whatever else may be part of such a sequence).<br>
>><br>
> <br>
> The TLS sequences are parts of TLS ABI.  Linker may transform them<br>
> to different sequences.  There is nothing to do for legacy encoding.<br>
<br>
IOW any legacy encoded insn is okay to use with this relocation. Yet<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Linker won't perform transformation for other sequences, legacy or not.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
only (only!) ADD is when it comes to EVEX-encoded ones. I'm sorry, but<br>
no, this doesn't make any sense to me.<br>
<br>
Jan<br>
</blockquote></div></div></div>