[PATCH 4/7] x86: improve match_template()'s diagnostics

H.J. Lu hjl.tools@gmail.com
Thu Aug 18 14:51:15 GMT 2022


On Wed, Aug 17, 2022 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.08.2022 22:24, H.J. Lu wrote:
> > On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> At the example of
> >>
> >>         extractps $0, %xmm0, %xmm0
> >>         insertps $0, %xmm0, %eax
> >>
> >> (both having respectively the same mistake of using the wrong kind of
> >> destination register) it is easy to see that current behavior is far
> >> from ideal: The former results in "unsupported instruction" for 32-bit
> >> code simply because the 2nd template we have is a Cpu64 one. Instead we
> >> should aim at emitting the "best" possible error, which will typically
> >> be the one where we passed the largest number of checks. Generalize the
> >> original "specific_error" approach by making it apply to the entire
> >> matching loop, utilizing that line numbers increase as we pass further
> >> checks.
> >> ---
> >> As to the inval-tls testcase: Why is KMOV special? Are e.g. VMOV or
> >> other vector insns (legacy or EVEX-encoded) any different? Shouldn't the
> >> use of the respective reloc types be limited to _exactly_ the insns they
> >> are intended to be used with? Furthermore having this check in
> >> match_template() is unhelpful, as the resulting diagnostic isn't aiding
> >> in understanding what's wrong. Template matching should be left alone
> >> here, and the issue be diagnosed later, say directly in md_assemble()
> >> (alongside the various further consistency checks there) or in
> >> process_operands().
> >
> > GCC may generate invalid TLS code sequences with KMOV, not other
> > instructions.  We want to catch them by assembler.   It is easier to disallow
> > the invalid instructions.
>
> I did actually check both the discussion and gcc code in question, and I
> was not able to prove that it could have done so only for KMOV. And yes,
> I agree with disallowing the invalid instructions. The question is why
> we do so only for a limited and inconsistent subset.

So far, linker only sees it with KMOV.  Linker will issue an error if other
instructions are used.

> In addition you don't say anything regarding the point in time when we
> diagnose this, the placement of which - as said - looks sub-optimal to me.
>

Improvement is welcome.

-- 
H.J.


More information about the Binutils mailing list