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

[H.J. Lu]

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


-- 
H.J.