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

[Florian Weimer <fweimer at redhat dot com>]

* Rafal Luzynski:

> 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.

Well, I initially wrote a long reply, explaining that a Fedora GCC
package with a .1 version is special and likely requires updates sooner
than later.

But that was a bit off target because I eventually realized that GCC 6.3
in Debian stretch has the same bug. 8->

I do think the test case is valuable (it catches two totally distinct
toolchain problems, one in GCC, one binutils), so I'm rather hesitant to
XFAIL it.

I don't know how feasible it is at this point to get Debian stretch
fixed, given that the distribution is rather late in its life-cycle.
(Upstream GCC did backport a fix to the GCC 6 branch, though.)

I can file bugs for this issue in various bug trackers and document it
on the wiki in the release notes.  Would this be sufficient?

Thanks,
Florian