[PATCH] Linux/x86: Configure gas with --enable-x86-used-note by default

[Jan Beulich]

On 13.07.2020 18:06, H.J. Lu wrote:
> On Mon, Jul 13, 2020 at 8:48 AM Michael Matz <matz@suse.de> wrote:
>>
>> Hello,
>>
>> On Mon, 13 Jul 2020, H.J. Lu wrote:
>>
>>>>>>>> I'm quite unconvinced this is a good idea as long as the contents of
>>>>>>>> these notes are neither reliable nor properly settled on what they
>>>>>>>> actually mean. This should be considered an experimental feature for
>>>>>>>> now, and hence would better not be enabled by default to avoid
>>>>>>>> future backwards compatibility issues.
>>>>>>>>
>>>>>>>
>>>>>>> It has been an experimental feature for 2 years.
>>>>>>
>>>>>> And when I asked questions about the underlying spec I did get at
>>>>>> best fuzzy answers from you. I still have on my todo list to get
>>>>>> this in shape with a pretty recent reply of yours, which was
>>>>>> supporting my view on how things should be (and why things are
>>>>>> broken right now), and hence somewhat contrary to earlier replies
>>>>>> of yours.
>>>>>>
>>>>>> To just name the most unclear (to me) aspect of what's there
>>>>>> currently: What's the distinction between xmm, ymm, and zmm, when
>>>>>> zmm is a superset of ymm (and ymm one of xmm), yet at the same
>>>>>> time AVX512 writes to xmm mean writes to ymm and zmm (zeroing
>>>>>> upper parts) as well. From my observations e.g. an AVX512 insn
>>>>>> accessing just xmm registers will record just an xmm dependency,
>>>>>> which then is simply wrong - the resulting binary in fact depends
>>>>>> on all of xmm, ymm, zmm, and the mask registers. IIRC I proposed
>>>>>> back then to tie what an insn records to the XCR0 bits it
>>>>>> requires to be set in order for it to not fault.
>>>>>
>>>>> Should we add a field to i386 opcode table for this?
>>>>>
>>>>>>>  Let's see what fallouts will be.
>>>>>>
>>>>>> Fallout may become noticeable only when the behavior of the notes
>>>>>> changes: People may start noticing that new (correct) dependencies
>>>>>> prevent things from working (assuming there's any consumer of
>>>>>> these notes).
>>>>>>
>>>>>
>>>>> We have a couple months to address this before 2.36 is released.
>>>>
>>>> FWIW, as data point, if this option becomes default for 2.35 I'll patch it
>>>> out again for our distro binutils.  I really really want to avoid
>>>> spreading binaries with these notes into the wild in the current state.
>>>> Whenever I look at them my guts grumble and I think they are ill-defined.
>>>>
>>>> The past attempts to clarify them (or to create better defined
>>>> alternatives) never lead to anything like a agreement amongst affected
>>>> parties, so this change in default seems to be work-around for that by
>>>> creating unchangable facts.
>>>>
>>>
>>> Please open bugs for issues you find.
>>>
>>> Thanks.
>>
>> I'm not talking about bugs in the implementation.  I'm talking about the
>> whole design of these notes.  Over the years I tried multiple times to
>> start a discussion about that, it never lead to anywhere and I can't
>> imagine this changing if I start again, so I'll not.  But I'll do whatever
>> I can to prevent spreading binaries containing those notes.
>>
> 
> There is a potential use case now:
> 
> https://sourceware.org/pipermail/libc-alpha/2020-July/116135.html

I'm sorry for repeating myself, but imo it is a _prereq_ for such a
use case that things are both well specified and sufficiently well
implemented (see e.g. my remark regarding testsuite coverage).

Jan