Re: [PATCH] elf: Add tests with a local IFUNC resolver [BZ #23937]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Mar 12, 2019 at 5:57 AM Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
>
> 11.03.2019 14:55 Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Rafal Luzynski:
> >
> > > [...]
> > > I've made several more tests during the weekend and it seems that
> > > it's GCC version what matters.  Just to summarize: my basic test
> > > environment is Fedora 24 (yes, I know, it is old) but I am able to
> > > install packages from newer versions.  I definitely have not tested
> > > every single version of GCC but 7.2.1-2 and everything newer worked
> > > fine while 7.1.1-3 and everything older failed at these tests.
> > > I did not touch binutils during these tests so I assume that its
> > > version does not matter.
> >
> > I think this is GCC PR81128, see this comment:
> >
> >   <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81128#c4>
> >
> > The return value reported suggests that: it does look like an address in
> > the executable.
>
> I have not analyzed everything but it looks like the same issue at first
> sight.
>
> > My motivation in adding this test case was to catch such bugs earlier
> > because clearly, the corresponding GCC tests are not prominent enough
> > (or do not cover all relevant usage scenarios).
> >
> > > Thoughts?  Should we state that GCC 7.2 is a minimum required version
> > > to build Glibc?  Should these tests have additional checks and XFAIL
> > > in some versions of GCC?  Should we assume that the failures are
> > > correct and Glibc may be compiled with that particular version of GCC
> > > but only if GCC has some patches fixing any known bugs?
> >
> > I think your use case is really unusual.  I expect that distributions
> > backport upstream bug fixes like this, and I assume Fedora did.  You
> > just didn't update back then.
>
> If I understand correctly, the unusual part is that I'm using the gcc
> compiler with known bugs for which patches exist.  What's your advice
> here?  Should glibc detect the bug in the configure script and say that
> it will not build correctly with this compiler?  Should the test case
> be reworked to ignore the bug?  Or should I assume that the test failure
> is the way to tell that we are using gcc with bugs?  Should we suggest
> in the error message that maybe there are bugs in the compiler instead
> of some cryptic "result is 0, should be 1"?

Glibc itself is OK.  The problem is that GCC fails these particular tests.

-- 
H.J.