[PATCH] x86: Disallow GOT memory as vector memory operand

[Jan Beulich]

On 06.02.2025 04:18, H.J. Lu wrote:
> On Wed, Feb 5, 2025 at 4:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 04.02.2025 23:19, H.J. Lu wrote:
>>> GOT memory is 4-byte for i386 and 8-byte for x86-64.  Disallow GOT memory
>>> as vector memory operand.
>>
>> This is going too far and not far enough at the same time.
>>
>> Too far: Assembly programmers ought to be permitted to do whatever
>> they like. There may be an advanced mode where we warn about things
>> we deem bogus.
> 
> Assembler doesn't allow a word memory operand when instruction
> requires a 128-bit memory operand.

I can't connect your reply to my comment.

>> Not far enough: Why would non-vector operands of the wrong size be
>> okay? (Correcting this can then easily go too far, though: If
>> one is after a specific property of a GOT entry, TEST or CMP may,
>> for example, be used on just the high part [of whatever size] of
>> it.)
> 
> Smaller than GOT slot size should be OK.

vpbroadcast{b,w,d,q}? cmpxchg{8,16}b? (Just to name two falling in
opposite categories in this regard. Not to speak of {F,FX,X}{SAVE,RSTOR}
and alike.)

>> Overall: This is yet another arbitrary heuristic you're introducing.
>> I did complain about you doing such already in the past. Please
>> don't. Either there are firm, psABI-mandated criteria, or there
>> aren't. As said above, a default-off optional check may be okay.
>>
>> Furthermore, why would you check the template for dword/qword?
> 
> Some vector instructions take dword/qword and vector memory.

Correct. And why would such an operand not be permitted to live in
GOT?

>> Shouldn't this be the actual operand that we're processing? While
> 
> It sounds good.  But it is more complex than I like.

IOW if already it's arbitrary, it can be arbitrarily arbitrary? At
the risk of sounding like a broken record: Assembler behavior should
be as predictable as possible for a programmer using it.

Jan