[PATCH V5] x86: Add tls check in gas

Cui, Lili lili.cui@intel.com
Mon Oct 14 10:06:36 GMT 2024



> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, October 11, 2024 6:04 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: binutils@sourceware.org; hjl.tools@gmail.com
> Subject: Re: [PATCH V5] x86: Add tls check in gas
> 
> On 11.10.2024 11:28, Cui, Lili wrote:
> >> On 19.09.2024 08:38, Cui, Lili wrote:
> >>> +    case BFD_RELOC_386_TLS_GOTIE:
> >>> +      /* Check GOTIE access model:
> >>> +
> >>> +	 subl foo@gotntpoff(%reg1), %reg2
> >>> +	 movl foo@gotntpoff(%reg1), %reg2
> >>> +	 addl foo@gotntpoff(%reg1), %reg2
> >>> +
> >>> +	 Memory operand: SIB is not supported.
> >>> +       */
> >>> +    case BFD_RELOC_386_TLS_IE_32:
> >>> +      /* Check IE_32 access model:
> >>> +
> >>> +	 subl foo@gottpoff(%reg1), %reg2
> >>> +	 movl foo@gottpoff(%reg1), %reg2
> >>> +	 addl foo@gottpoff(%reg1), %reg2
> >>> +
> >>> +	 Memory operand: SIB is not supported.
> >>> +       */
> >>> +      if (i.tm.mnem_off != MN_sub
> >>> +	  && i.tm.mnem_off != MN_add
> >>> +	  && i.tm.mnem_off != MN_mov)
> >>> +	return x86_tls_error_insn;
> >>> +      if (i.op[1].regs->reg_type.bitfield.class != Reg
> >>> +	  || i.op[0].regs->reg_type.bitfield.class
> >>> +	  || i.imm_operands)
> >>
> >> You may not de-reference i.op[0].regs for the intended forms at all.
> >> If anything, i.op[0].disps may be de-referenced there.
> >>
> >> You may also not de-reference i.op[1].regs until you've checked that
> >> operand 1 actually is a register. There are insn forms after all
> >> where operand 1 is a memory one.
> >>
> >> Which member of the union is valid to de-reference can only be told
> >> by inspecting i.types[] and/or i.tm.operand_types[] (when insns are
> >> more constrained than mov/add/sub are, going from just
> >> i.{reg,imm,mem,disp}_operands may also be possible, just to mention it).
> >>
> >> I expect you want to check for operand counts first: No immediate
> >> one, a single disp one, and a single register one. Then check that
> >> it's the destination that's the register one. There may then not be
> >> any need to access any i.op[<n>].reg anymore.
> >>
> >
> > Jan, do you mean to modify it like this?
> >
> > diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c index
> > 25ecaa66104..358d76e7bd2 100644
> > --- a/gas/config/tc-i386.c
> > +++ b/gas/config/tc-i386.c
> > @@ -6545,9 +6545,10 @@ x86_check_tls_relocation (enum
> bfd_reloc_code_real r_type)
> >           && i.tm.mnem_off != MN_add
> >           && i.tm.mnem_off != MN_mov)
> >         return x86_tls_error_insn;
> > -      if (i.op[1].regs->reg_type.bitfield.class != Reg
> > -         || i.op[0].regs->reg_type.bitfield.class
> > -         || i.imm_operands)
> > +      if (i.imm_operands
> > +         || i.disp_operands != 1
> > +         || i.reg_operands != 1
> > +         || i.types[1].bitfield.class != Reg)
> >         return x86_tls_error_opcode;
> 
> This goes in the right direction, but still isn't quite enough, I fear.
> Knowing there's 1 disp and 1 reg operand still doesn't tell you which one is which
> (both forms exist, after all). 

"i.types[1].bitfield.class != Reg" requires dest to be reg, so source should be disp.

>Plus because of APX there are also 3-operand forms
> of SUB and ADD (but of course not MOV).
> 

For APX the 3-operand form, there are two types,

1 imm + 2 others   :  “i.imm_operands”  can exclude this situation.
1 dis + 2 regs          :  “i.reg_operands != 1” can exclude this situation.


Thanks,
Lili.




> Jan


More information about the Binutils mailing list