This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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"?

Regards,

Rafal


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]