<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2024, 3:27 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 03.07.2024 09:14, H.J. Lu wrote:<br>
> On Wed, Jul 3, 2024, 3:10 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br>
> <br>
>> On 03.07.2024 08:48, H.J. Lu wrote:<br>
>>> On Wed, Jul 3, 2024, 2:43 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br>
>>><br>
>>>> On 03.07.2024 03:55, H.J. Lu wrote:<br>
>>>>> On Wed, Jul 3, 2024, 9:19 AM kong lingling <<a href="mailto:lingling.kong7@gmail.com" target="_blank" rel="noreferrer">lingling.kong7@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>>> Support APX NF TLS IE with 2 operands.Verify it with ld and gold.<br>
>>>>>><br>
>>>>>> gas/<br>
>>>>>><br>
>>>>>> * config/tc-i386.c (md_assemble): Allow APX NF TLS IE with<br>
>>>>>> 2 operands.<br>
>>>>>> * testsuite/gas/i386/x86-64-gottpoff.d: Updated.<br>
>>>>>> * testsuite/gas/i386/x86-64-gottpoff.s: Add APX NF TLS IE<br>
>>>>>> tests with 2 operands.<br>
>>>>>><br>
>>>>>> gold/<br>
>>>>>><br>
>>>>>> * testsuite/x86_64_ie_to_le.s: Add APX NF TLS IE tests with<br>
>>>>>> 2 operands.<br>
>>>>>> * testsuite/x86_64_ie_to_le.sh: Updated.<br>
>>>>>><br>
>>>>>> ld/<br>
>>>>>><br>
>>>>>> * testsuite/ld-x86-64/tlsbindesc.s: Add APX NF TLS IE tests<br>
>>>>>> with 2 operands.<br>
>>>>>> * testsuite/ld-x86-64/tlsbindesc.d: Updated.<br>
>>>>>> * testsuite/ld-x86-64/tlsbindesc.rd: Likewise.<br>
>>>>>> ---<br>
>>>>>> gas/config/tc-i386.c | 10 +++++--<br>
>>>>>> gas/testsuite/gas/i386/x86-64-gottpoff.d | 4 +++<br>
>>>>>> gas/testsuite/gas/i386/x86-64-gottpoff.s | 10 +++++++<br>
>>>>>> gold/testsuite/x86_64_ie_to_le.s | 1 +<br>
>>>>>> gold/testsuite/x86_64_ie_to_le.sh | 1 +<br>
>>>>>> ld/testsuite/ld-x86-64/tlsbindesc.dd | 12 ++++++++<br>
>>>>>> ld/testsuite/ld-x86-64/tlsbindesc.rd | 36<br>
>> ++++++++++++------------<br>
>>>>>> ld/testsuite/ld-x86-64/tlsbindesc.s | 4 +++<br>
>>>>>> 8 files changed, 58 insertions(+), 20 deletions(-)<br>
>>>>>><br>
>>>>>> --- a/gas/config/tc-i386.c<br>
>>>>>> +++ b/gas/config/tc-i386.c<br>
>>>>>> @@ -7545,8 +7545,14 @@ 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>
>>>>>> - /* Allow APX: add %reg1, foo@gottpoff(%rip), %reg2. */<br>
>>>>>> + && (i.tm.operand_types[2].bitfield.class == Reg<br>
>>>>>> + || i.tm.operands == 2))<br>
>>>>>> + /* Allow APX:<br>
>>>>>> + add %reg1, foo@gottpoff(%rip), %reg2<br>
>>>>>> + add foo@gottpoff(%rip), %reg, %reg2<br>
>>>>>> + {nf} add foo@gottpoff(%rip), %reg<br>
>>>>>> + {nf} add %reg1, foo@gottpoff(%rip), %reg2<br>
>>>>>> + {nf} add foo@gottpoff(%rip), %reg, %reg2. */<br>
>>>>>> break;<br>
>>>>>> /* Fall through. */<br>
>>>>>> case BFD_RELOC_386_TLS_GOTIE:<br>
>>>>>> [...]<br>
>>>>>> --<br>
>>>>>> 2.31.1<br>
>>>>>><br>
>>>>><br>
>>>>> OK.<br>
>>>><br>
>>>> H.J., please don't do this when you're well aware that earlier comments<br>
>>>> of others (me in this case) were not addressed. The code left in context<br>
>>>> above _STILL_ permits memory destinations for the 2-operand case,<br>
>> despite<br>
>>>> the comment saying otherwise. Plus the EVEX and legacy cases are still<br>
>>>> being treated vastly different.<br>
>>>><br>
>>>> Lingling, I notice you committed the patch with H.J.'s approval above,<br>
>>>> despite knowing there were open issues. I'm going to expect an<br>
>>>> incremental change to at least address the former of the two issues.<br>
>>>> Should that not arrive within a couple of days, I'm afraid I'm going to<br>
>>>> need to revert your change, for having been committed prematurely /<br>
>>>> unduly. You having done so is even more so odd because the requested<br>
>>>> adjustment would actually have simplified the code:<br>
>>>><br>
>>>> if (i.tm.mnem_off == MN_add<br>
>>>> && i.tm.opcode_space == SPACE_EVEXMAP4<br>
>>>> && i.mem_operands == 1<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[i.operands - 1].bitfield.class ==<br>
>>>> Reg)<br>
>>>><br>
>>>> For the latter of the two issues, if H.J. is unwilling to actually<br>
>>>> settle on consistent criteria between legacy and EVEX encodings, I guess<br>
>>>> it'll end up being me to actually make this code consistent, one way or<br>
>>>> another. The unwillingness to settle on criteria up front means that<br>
>>>> there then shall not be objections later on.<br>
>>><br>
>>> Please open a bug report with a testcase.<br>
>><br>
>> You're kidding? The inconsistency is blatantly obvious. And any testcase is<br>
>> going to be contrived anyway, as what we're discussing here is inconsistent<br>
>> application of an underlying, unwritten policy: How much is the assembler<br>
>> supposed to be refusing? How much control is the assembler supposed to be<br>
>> leaving to the programmer? I can live with such a policy being unwritten; I<br>
>> can't accept such a policy to be applied inconsistently (and hence<br>
>> unpredictably for the programmer).<br>
> <br>
> TLS sequence is a special case. It is hard to tell what your issues are<br>
> without a testcase.<br>
<br>
I firmly explained what the issue with this is. Whereas you're firmly refusing<br>
to give an at least halfway appropriate response.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Have I missed something? I haven't seen any testcases.</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">
<br>
Jan<br>
</blockquote></div></div></div>