[PATCH] x86-64: Relax BFD_RELOC_X86_64_GOTTPOFF check

[H.J. Lu]

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.


> I'd also wonder, btw., whether CFCMOVcc or EVEX-encoded CMOVcc couldn't
> be a possible part of such a sequence, going forward.
>

TLS ABI must be updated first.


> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240628/ea3662b1/attachment.htm>