[PATCH] x86-64: Relax BFD_RELOC_X86_64_GOTTPOFF check

[Jan Beulich]

On 27.06.2024 23:18, H.J. Lu wrote:
> On Thu, Jun 27, 2024, 10:39 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 27.06.2024 15:59, H.J. Lu wrote:
>>> On Thu, Jun 27, 2024, 5:25 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>>> On 27.06.2024 08:06, Kong, Lingling wrote:
>>>>>> --- a/gas/config/tc-i386.c
>>>>>> +++ b/gas/config/tc-i386.c
>>>>>> @@ -7137,7 +7137,8 @@ md_assemble (char *line)
>>>>>>              && i.base_reg
>>>>>>              && i.base_reg->reg_num == RegIP
>>>>>>              && i.tm.operand_types[0].bitfield.class == Reg
>>>>>> -            && i.tm.operand_types[2].bitfield.class == Reg)
>>>>>> +            && (i.tm.operand_types[2].bitfield.class == Reg
>>>>>> +                || (i.tm.operands == 2 && i.tm.opcode_modifier.nf)))
>>>>>>            /* Allow APX: add %reg1, foo@gottpoff(%rip), %reg2.  */
>>>>>>            break;
>>>>
>>>> What does the i.tm.opcode_modifier.nf check achieve here? All EVexMap4
>>>> ADD forms permit {nf}. The comment also needs updating, to avoid it
>>>> going further stale (it already hasn't been quite accurate). With the
>>>> comment properly updated to list all permissible forms, I think you'll
>>>> also note that what you add to the condition is too lax: Aiui
>>>>
>>>>         add %rax, foo@GOTTPOFF(%rip)
>>>>
>>>> is not supposed to be permitted (according to the testsuite additions
>>>> you make).
>>>>
>>>> Finally a question perhaps more for H.J. than for you: Why is it that
>>>> ADD is special-cased here for the APX EVEX-encoded case, when there's
>>>> no similar special casing for legacy encodings?
>>>
>>> ADD is the part of TLS sequence.
>>
>> I expected you would say that, but it doesn't answer my question: Why a
>> special case for EVEX-encoded ADD but not a special case for legacy
>> encoded ADD/MOV (and whatever else may be part of such a sequence).
>>
> 
> The TLS sequences are parts of TLS ABI.  Linker may transform them
> to different sequences.  There is nothing to do for legacy encoding.

IOW any legacy encoded insn is okay to use with this relocation. Yet
only (only!) ADD is when it comes to EVEX-encoded ones. I'm sorry, but
no, this doesn't make any sense to me.

Jan