[PATCH] x86-64: Relax BFD_RELOC_X86_64_GOTTPOFF check

[H.J. Lu]

On Fri, Jun 28, 2024, 2:11 PM Jan Beulich <jbeulich@suse.com> wrote:

> 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
>

Linker won't perform transformation for other sequences, legacy or not.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240628/3215ec65/attachment.htm>