diff mbox series

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

Message ID 87mumqei4h.fsf@oldenburg2.str.redhat.com
State New
Headers show
Series elf: Add tests with a local IFUNC resolver [BZ #23937] | expand

Commit Message

Florian Weimer Feb. 20, 2019, 12:53 p.m. UTC
The existing tests all use global symbols (but with different
visibility).  Local symbols could be treated differently by the
compiler and linker (as was the case on POWER ELFv2, causing
bug 23937), and we did not have test coverage for this.

Tested on x86-64 and POWER ELFv2 little-endian, with and without
--disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
binutils.

2019-02-20  Florian Weimer  <fweimer@redhat.com>

	[BZ #23937]
	elf: Add test with a local IFUNC resolver.
	* elf/ifuncmain9.c: New file.
	* elf/ifuncmain9pic.c: Likewise.
	* elf/ifuncmain9picstatic.c: Likewise.
	* elf/ifuncmain9pie.c: Likewise.
	* elf/ifuncmain9static.c: Likewise.
	* elf/Makefile [multi-arch] (tests-ifuncstatic): Add
	ifuncmain9static, ifuncmain9picstatic.
	* elf/Makefile [multi-arch && build-shared] (tests-internal):
	Add ifuncmain9, ifuncmain9pic.
	* elf/Makefile [multi-arch && build-shared && have-fpie]
	(ifunc-pie-tests): Add ifuncmain9pie.
	(CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
	(CFLAGS-ifuncmain9picstatic.c): Likewise.
	(CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).

Comments

H.J. Lu Feb. 20, 2019, 1:16 p.m. UTC | #1
On Wed, Feb 20, 2019 at 4:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> The existing tests all use global symbols (but with different
> visibility).  Local symbols could be treated differently by the
> compiler and linker (as was the case on POWER ELFv2, causing
> bug 23937), and we did not have test coverage for this.
>
> Tested on x86-64 and POWER ELFv2 little-endian, with and without
> --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
> elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
> binutils.
>
> 2019-02-20  Florian Weimer  <fweimer@redhat.com>
>
>         [BZ #23937]
>         elf: Add test with a local IFUNC resolver.
>         * elf/ifuncmain9.c: New file.
>         * elf/ifuncmain9pic.c: Likewise.
>         * elf/ifuncmain9picstatic.c: Likewise.
>         * elf/ifuncmain9pie.c: Likewise.
>         * elf/ifuncmain9static.c: Likewise.
>         * elf/Makefile [multi-arch] (tests-ifuncstatic): Add
>         ifuncmain9static, ifuncmain9picstatic.
>         * elf/Makefile [multi-arch && build-shared] (tests-internal):
>         Add ifuncmain9, ifuncmain9pic.
>         * elf/Makefile [multi-arch && build-shared && have-fpie]
>         (ifunc-pie-tests): Add ifuncmain9pie.
>         (CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
>         (CFLAGS-ifuncmain9picstatic.c): Likewise.
>         (CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).
>

It isn't caused by your patch.  I am wondering why we don't run IFUNC
tests with --disable-multi-arch.  Multi-arch requires IFUNC.  Does IFUNC
require multi-arch?
Florian Weimer Feb. 20, 2019, 1:29 p.m. UTC | #2
* H. J. Lu:

> On Wed, Feb 20, 2019 at 4:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> The existing tests all use global symbols (but with different
>> visibility).  Local symbols could be treated differently by the
>> compiler and linker (as was the case on POWER ELFv2, causing
>> bug 23937), and we did not have test coverage for this.
>>
>> Tested on x86-64 and POWER ELFv2 little-endian, with and without
>> --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
>> elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
>> binutils.
>>
>> 2019-02-20  Florian Weimer  <fweimer@redhat.com>
>>
>>         [BZ #23937]
>>         elf: Add test with a local IFUNC resolver.
>>         * elf/ifuncmain9.c: New file.
>>         * elf/ifuncmain9pic.c: Likewise.
>>         * elf/ifuncmain9picstatic.c: Likewise.
>>         * elf/ifuncmain9pie.c: Likewise.
>>         * elf/ifuncmain9static.c: Likewise.
>>         * elf/Makefile [multi-arch] (tests-ifuncstatic): Add
>>         ifuncmain9static, ifuncmain9picstatic.
>>         * elf/Makefile [multi-arch && build-shared] (tests-internal):
>>         Add ifuncmain9, ifuncmain9pic.
>>         * elf/Makefile [multi-arch && build-shared && have-fpie]
>>         (ifunc-pie-tests): Add ifuncmain9pie.
>>         (CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
>>         (CFLAGS-ifuncmain9picstatic.c): Likewise.
>>         (CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).
>
> It isn't caused by your patch.  I am wondering why we don't run IFUNC
> tests with --disable-multi-arch.  Multi-arch requires IFUNC.  Does IFUNC
> require multi-arch?

Hah.  I wondered the same thing.  Yes, we can run IFUNC tests with
--disable-multi-arch if the toolchain supports IFUNCs.  For correctness,
--disable-multi-arch must not remove IFUNC support from the loader.

I do not know what the exact rules for IFUNC support in the loader are.
Logically, support cannot depend on whether the toolchain supports
IFUNCs because it's a property of the ABI.  Calling IFUNCs in the loader
should not require toolchain support, only internal use in glibc and
tests need it.

Thanks,
Florian
Szabolcs Nagy Feb. 20, 2019, 2:01 p.m. UTC | #3
On 20/02/2019 13:29, Florian Weimer wrote:
> * H. J. Lu:
> 
>> On Wed, Feb 20, 2019 at 4:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> The existing tests all use global symbols (but with different
>>> visibility).  Local symbols could be treated differently by the
>>> compiler and linker (as was the case on POWER ELFv2, causing
>>> bug 23937), and we did not have test coverage for this.
>>>
>>> Tested on x86-64 and POWER ELFv2 little-endian, with and without
>>> --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
>>> elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
>>> binutils.
>>>
>>> 2019-02-20  Florian Weimer  <fweimer@redhat.com>
>>>
>>>         [BZ #23937]
>>>         elf: Add test with a local IFUNC resolver.
>>>         * elf/ifuncmain9.c: New file.
>>>         * elf/ifuncmain9pic.c: Likewise.
>>>         * elf/ifuncmain9picstatic.c: Likewise.
>>>         * elf/ifuncmain9pie.c: Likewise.
>>>         * elf/ifuncmain9static.c: Likewise.
>>>         * elf/Makefile [multi-arch] (tests-ifuncstatic): Add
>>>         ifuncmain9static, ifuncmain9picstatic.
>>>         * elf/Makefile [multi-arch && build-shared] (tests-internal):
>>>         Add ifuncmain9, ifuncmain9pic.
>>>         * elf/Makefile [multi-arch && build-shared && have-fpie]
>>>         (ifunc-pie-tests): Add ifuncmain9pie.
>>>         (CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
>>>         (CFLAGS-ifuncmain9picstatic.c): Likewise.
>>>         (CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).
>>
>> It isn't caused by your patch.  I am wondering why we don't run IFUNC
>> tests with --disable-multi-arch.  Multi-arch requires IFUNC.  Does IFUNC
>> require multi-arch?
> 
> Hah.  I wondered the same thing.  Yes, we can run IFUNC tests with
> --disable-multi-arch if the toolchain supports IFUNCs.  For correctness,
> --disable-multi-arch must not remove IFUNC support from the loader.
> 
> I do not know what the exact rules for IFUNC support in the loader are.
> Logically, support cannot depend on whether the toolchain supports
> IFUNCs because it's a property of the ABI.  Calling IFUNCs in the loader
> should not require toolchain support, only internal use in glibc and
> tests need it.

gcc rejects __attribute__((ifunc( ))) if the compiler
was not configured with --enable-gnu-indirect-function
(which i think is not default on some targets e.g. arm)

(i think gcc should just handle the attribute and
emit the gas directive if there is gas support anyway,
and the configure flag should only affect target libs
in gcc that use ifunc like libatomic)
Florian Weimer Feb. 27, 2019, 10:27 a.m. UTC | #4
* Florian Weimer:

> The existing tests all use global symbols (but with different
> visibility).  Local symbols could be treated differently by the
> compiler and linker (as was the case on POWER ELFv2, causing
> bug 23937), and we did not have test coverage for this.
>
> Tested on x86-64 and POWER ELFv2 little-endian, with and without
> --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
> elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
> binutils.
>
> 2019-02-20  Florian Weimer  <fweimer@redhat.com>
>
> 	[BZ #23937]
> 	elf: Add test with a local IFUNC resolver.
> 	* elf/ifuncmain9.c: New file.
> 	* elf/ifuncmain9pic.c: Likewise.
> 	* elf/ifuncmain9picstatic.c: Likewise.
> 	* elf/ifuncmain9pie.c: Likewise.
> 	* elf/ifuncmain9static.c: Likewise.
> 	* elf/Makefile [multi-arch] (tests-ifuncstatic): Add
> 	ifuncmain9static, ifuncmain9picstatic.
> 	* elf/Makefile [multi-arch && build-shared] (tests-internal):
> 	Add ifuncmain9, ifuncmain9pic.
> 	* elf/Makefile [multi-arch && build-shared && have-fpie]
> 	(ifunc-pie-tests): Add ifuncmain9pie.
> 	(CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
> 	(CFLAGS-ifuncmain9picstatic.c): Likewise.
> 	(CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).

Ping?  <https://sourceware.org/ml/libc-alpha/2019-02/msg00503.html>

Thanks,
Florian
H.J. Lu Feb. 27, 2019, 9:23 p.m. UTC | #5
On Wed, Feb 20, 2019 at 4:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> The existing tests all use global symbols (but with different
> visibility).  Local symbols could be treated differently by the
> compiler and linker (as was the case on POWER ELFv2, causing
> bug 23937), and we did not have test coverage for this.
>
> Tested on x86-64 and POWER ELFv2 little-endian, with and without
> --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
> elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
> binutils.
>
> 2019-02-20  Florian Weimer  <fweimer@redhat.com>
>
>         [BZ #23937]
>         elf: Add test with a local IFUNC resolver.
>         * elf/ifuncmain9.c: New file.
>         * elf/ifuncmain9pic.c: Likewise.
>         * elf/ifuncmain9picstatic.c: Likewise.
>         * elf/ifuncmain9pie.c: Likewise.
>         * elf/ifuncmain9static.c: Likewise.
>         * elf/Makefile [multi-arch] (tests-ifuncstatic): Add
>         ifuncmain9static, ifuncmain9picstatic.
>         * elf/Makefile [multi-arch && build-shared] (tests-internal):
>         Add ifuncmain9, ifuncmain9pic.
>         * elf/Makefile [multi-arch && build-shared && have-fpie]
>         (ifunc-pie-tests): Add ifuncmain9pie.
>         (CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
>         (CFLAGS-ifuncmain9picstatic.c): Likewise.
>         (CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).
>

LGTM.

Thanks.
Rafal Luzynski March 1, 2019, 12:50 a.m. UTC | #6
Florian,

27.02.2019 11:27 Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Florian Weimer:
> 
> > The existing tests all use global symbols (but with different
> > visibility).  Local symbols could be treated differently by the
> > compiler and linker (as was the case on POWER ELFv2, causing
> > bug 23937), and we did not have test coverage for this.
> >
> > Tested on x86-64 and POWER ELFv2 little-endian, with and without
> > --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
> > elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
> > binutils.
> >
> > 2019-02-20  Florian Weimer  <fweimer@redhat.com>
> >
> > 	[BZ #23937]
> > 	elf: Add test with a local IFUNC resolver.
> > 	* elf/ifuncmain9.c: New file.
> > 	* elf/ifuncmain9pic.c: Likewise.
> > 	* elf/ifuncmain9picstatic.c: Likewise.
> > 	* elf/ifuncmain9pie.c: Likewise.
> > 	* elf/ifuncmain9static.c: Likewise.
> > 	* elf/Makefile [multi-arch] (tests-ifuncstatic): Add
> > 	ifuncmain9static, ifuncmain9picstatic.
> > 	* elf/Makefile [multi-arch && build-shared] (tests-internal):
> > 	Add ifuncmain9, ifuncmain9pic.
> > 	* elf/Makefile [multi-arch && build-shared && have-fpie]
> > 	(ifunc-pie-tests): Add ifuncmain9pie.
> > 	(CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
> > 	(CFLAGS-ifuncmain9picstatic.c): Likewise.
> > 	(CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).

All those tests fail at my test machine:

FAIL: elf/ifuncmain9
FAIL: elf/ifuncmain9pic
FAIL: elf/ifuncmain9picstatic
FAIL: elf/ifuncmain9pie
FAIL: elf/ifuncmain9static

$ cat elf/ifuncmain9.out 
info: initial value of resolver_called: 0
error: invalid magic value: 0x400630
info: resolver_called value: 1
info: implementation_called value: 0
error: invalid implementation_called value (must be 1)
$ cat elf/ifuncmain9pic.out 
info: initial value of resolver_called: 0
error: invalid magic value: 0x400640
info: resolver_called value: 1
info: implementation_called value: 0
error: invalid implementation_called value (must be 1)
$ cat elf/ifuncmain9picstatic.out 
info: initial value of resolver_called: 0
error: invalid magic value: 0x400c70
info: resolver_called value: 1
info: implementation_called value: 0
error: invalid implementation_called value (must be 1)
$ cat elf/ifuncmain9pie.out 
info: initial value of resolver_called: 0
error: invalid magic value: 0x5ef358e0
info: resolver_called value: 1
info: implementation_called value: 0
error: invalid implementation_called value (must be 1)
$ cat elf/ifuncmain9static.out 
info: initial value of resolver_called: 0
error: invalid magic value: 0x400c60
info: resolver_called value: 1
info: implementation_called value: 0
error: invalid implementation_called value (must be 1)

I hope it helps.  Feel free to ask more questions.

Regards,

Rafal
H.J. Lu March 1, 2019, 1:52 a.m. UTC | #7
On Thu, Feb 28, 2019 at 4:50 PM Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
>
> Florian,
>
> 27.02.2019 11:27 Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Florian Weimer:
> >
> > > The existing tests all use global symbols (but with different
> > > visibility).  Local symbols could be treated differently by the
> > > compiler and linker (as was the case on POWER ELFv2, causing
> > > bug 23937), and we did not have test coverage for this.
> > >
> > > Tested on x86-64 and POWER ELFv2 little-endian, with and without
> > > --disable-multi-arch.  On POWER, the test cases elf/ifuncmain9,
> > > elf/ifuncmain9pic, elf/ifuncmain9pie reproduce bug 23937 with older
> > > binutils.
> > >
> > > 2019-02-20  Florian Weimer  <fweimer@redhat.com>
> > >
> > >     [BZ #23937]
> > >     elf: Add test with a local IFUNC resolver.
> > >     * elf/ifuncmain9.c: New file.
> > >     * elf/ifuncmain9pic.c: Likewise.
> > >     * elf/ifuncmain9picstatic.c: Likewise.
> > >     * elf/ifuncmain9pie.c: Likewise.
> > >     * elf/ifuncmain9static.c: Likewise.
> > >     * elf/Makefile [multi-arch] (tests-ifuncstatic): Add
> > >     ifuncmain9static, ifuncmain9picstatic.
> > >     * elf/Makefile [multi-arch && build-shared] (tests-internal):
> > >     Add ifuncmain9, ifuncmain9pic.
> > >     * elf/Makefile [multi-arch && build-shared && have-fpie]
> > >     (ifunc-pie-tests): Add ifuncmain9pie.
> > >     (CFLAGS-ifuncmain9pic.c): Add $(pic-ccflag).
> > >     (CFLAGS-ifuncmain9picstatic.c): Likewise.
> > >     (CFLAGS-ifuncmain9pie.c): Add $(pie-ccflag).
>
> All those tests fail at my test machine:

You left out the most relevant info.  What is your test machine?

> FAIL: elf/ifuncmain9
> FAIL: elf/ifuncmain9pic
> FAIL: elf/ifuncmain9picstatic
> FAIL: elf/ifuncmain9pie
> FAIL: elf/ifuncmain9static
>
> $ cat elf/ifuncmain9.out
> info: initial value of resolver_called: 0
> error: invalid magic value: 0x400630
> info: resolver_called value: 1
> info: implementation_called value: 0
> error: invalid implementation_called value (must be 1)
> $ cat elf/ifuncmain9pic.out
> info: initial value of resolver_called: 0
> error: invalid magic value: 0x400640
> info: resolver_called value: 1
> info: implementation_called value: 0
> error: invalid implementation_called value (must be 1)
> $ cat elf/ifuncmain9picstatic.out
> info: initial value of resolver_called: 0
> error: invalid magic value: 0x400c70
> info: resolver_called value: 1
> info: implementation_called value: 0
> error: invalid implementation_called value (must be 1)
> $ cat elf/ifuncmain9pie.out
> info: initial value of resolver_called: 0
> error: invalid magic value: 0x5ef358e0
> info: resolver_called value: 1
> info: implementation_called value: 0
> error: invalid implementation_called value (must be 1)
> $ cat elf/ifuncmain9static.out
> info: initial value of resolver_called: 0
> error: invalid magic value: 0x400c60
> info: resolver_called value: 1
> info: implementation_called value: 0
> error: invalid implementation_called value (must be 1)
>
> I hope it helps.  Feel free to ask more questions.
>
> Regards,
>
> Rafal
Rafal Luzynski March 1, 2019, 8:25 a.m. UTC | #8
1.03.2019 02:52 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> 
> On Thu, Feb 28, 2019 at 4:50 PM Rafal Luzynski
> <digitalfreak@lingonborough.com> wrote:
> > [...]
> > All those tests fail at my test machine:
> 
> You left out the most relevant info.  What is your test machine?

Usual and boring x86_64.  GCC version is 6.3.1.

Regards,

Rafal
Florian Weimer March 1, 2019, 8:41 a.m. UTC | #9
* Rafal Luzynski:

> 1.03.2019 02:52 "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> 
>> On Thu, Feb 28, 2019 at 4:50 PM Rafal Luzynski
>> <digitalfreak@lingonborough.com> wrote:
>> > [...]
>> > All those tests fail at my test machine:
>> 
>> You left out the most relevant info.  What is your test machine?
>
> Usual and boring x86_64.  GCC version is 6.3.1.

What's your binutils version?

Thanks,
Florian
Rafal Luzynski March 1, 2019, 11:03 a.m. UTC | #10
1.03.2019 09:41 Florian Weimer <fweimer@redhat.com> wrote:
> * Rafal Luzynski:
> > [...]
> > Usual and boring x86_64.  GCC version is 6.3.1.
> 
> What's your binutils version?

2.26.1

Regards,

Rafal
H.J. Lu March 1, 2019, 12:37 p.m. UTC | #11
On Fri, Mar 1, 2019 at 2:57 AM Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
>
> 1.03.2019 09:41 Florian Weimer <fweimer@redhat.com> wrote:
> > * Rafal Luzynski:
> > > [...]
> > > Usual and boring x86_64.  GCC version is 6.3.1.
> >
> > What's your binutils version?
>
> 2.26.1
>

Try binutils 2.32.
Rafal Luzynski March 2, 2019, 12:34 a.m. UTC | #12
1.03.2019 13:37 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> 
> On Fri, Mar 1, 2019 at 2:57 AM Rafal Luzynski
> <digitalfreak@lingonborough.com> wrote:
> >
> > 1.03.2019 09:41 Florian Weimer <fweimer@redhat.com> wrote:
> > > [...]
> > > What's your binutils version?
> >
> > 2.26.1
> >
> 
> Try binutils 2.32.

I've tried binutils-2.32-1.fc31.x86_64 from koji.fedoraproject.org
and it fails the same, just magic numbers slightly differ.

Regards,

Rafal
H.J. Lu March 2, 2019, 4:54 p.m. UTC | #13
On Fri, Mar 1, 2019 at 4:34 PM Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
>
> 1.03.2019 13:37 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Mar 1, 2019 at 2:57 AM Rafal Luzynski
> > <digitalfreak@lingonborough.com> wrote:
> > >
> > > 1.03.2019 09:41 Florian Weimer <fweimer@redhat.com> wrote:
> > > > [...]
> > > > What's your binutils version?
> > >
> > > 2.26.1
> > >
> >
> > Try binutils 2.32.
>
> I've tried binutils-2.32-1.fc31.x86_64 from koji.fedoraproject.org
> and it fails the same, just magic numbers slightly differ.
>

GCC 6.4.1 and binutils 2.31 branch work for me on x86-64.
Rafal Luzynski March 4, 2019, 9:47 a.m. UTC | #14
2.03.2019 17:54 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> 
> On Fri, Mar 1, 2019 at 4:34 PM Rafal Luzynski
> <digitalfreak@lingonborough.com> wrote:
> >
> > 1.03.2019 13:37 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> > >
> > > On Fri, Mar 1, 2019 at 2:57 AM Rafal Luzynski
> > > <digitalfreak@lingonborough.com> wrote:
> > > >
> > > > 1.03.2019 09:41 Florian Weimer <fweimer@redhat.com> wrote:
> > > > > [...]
> > > > > What's your binutils version?
> > > >
> > > > 2.26.1
> > > >
> > >
> > > Try binutils 2.32.
> >
> > I've tried binutils-2.32-1.fc31.x86_64 from koji.fedoraproject.org
> > and it fails the same, just magic numbers slightly differ.
> >
> 
> GCC 6.4.1 and binutils 2.31 branch work for me on x86-64.

Still the same failure.

I've also checked a similar virtual machine on another physical
machine and again the same failure which confirms that it is not
anything specific to one CPU model.

Does it maybe matter that all my tests are performed in virtual
machines controlled by VirtualBox?

Regards,

Rafal
Rafal Luzynski March 11, 2019, 11:16 a.m. UTC | #15
4.03.2019 10:47 Rafal Luzynski <digitalfreak@lingonborough.com> wrote:
> 
> 2.03.2019 17:54 "H.J. Lu" <hjl.tools@gmail.com> wrote:
> > 
> > [...]
> > GCC 6.4.1 and binutils 2.31 branch work for me on x86-64.
> 
> Still the same failure.
> 
> I've also checked a similar virtual machine on another physical
> machine and again the same failure which confirms that it is not
> anything specific to one CPU model.
> 
> Does it maybe matter that all my tests are performed in virtual
> machines controlled by VirtualBox?

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.

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?

Also, it's likely that it's not GCC what is problematic but some
other package pulled by GCC, for example libtool.

Please help.

Regards,

Rafal
Florian Weimer March 11, 2019, 1:55 p.m. UTC | #16
* Rafal Luzynski:

> 4.03.2019 10:47 Rafal Luzynski <digitalfreak@lingonborough.com> wrote:
>> 
>> 2.03.2019 17:54 "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> > 
>> > [...]
>> > GCC 6.4.1 and binutils 2.31 branch work for me on x86-64.
>> 
>> Still the same failure.
>> 
>> I've also checked a similar virtual machine on another physical
>> machine and again the same failure which confirms that it is not
>> anything specific to one CPU model.
>> 
>> Does it maybe matter that all my tests are performed in virtual
>> machines controlled by VirtualBox?
>
> 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.

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.

Thanks,
Florian
Rafal Luzynski March 11, 2019, 9:56 p.m. UTC | #17
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
H.J. Lu March 12, 2019, 1:12 a.m. UTC | #18
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.
Rafal Luzynski March 13, 2019, 11:47 a.m. UTC | #19
11.03.2019 14:55 Florian Weimer <fweimer@redhat.com> wrote:
> [...]
> 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.

Now I can confirm that GCC 7.2.1-1 which was the newest version
available in Fedora without this patch applied fails while GCC 7.2.1-2
which was the first version with this patch applied passes the tests.
Which, as far as I understand, means that I may have even an older
version of a compiler as long as it has this bug fixed.  There
would be no problem with GCC 6.2 or 6.4 except that Fedora does not
distribute them anymore and has never built a patched version.
The tests correctly fail notifying that there is a problem in GCC.

I have another issue which is little off-topic but also little
similar. While playing with different Fedora releases I noticed
that these two tests:

    resolv/tst-resolv-ai_idn
    resolv/tst-resolv-ai_idn-latin1

may or may not fail depending on the version of libidn2 installed.
Again, there is no specific version which we may recommend as a
minimum.  Sometimes newer versions may fail which suggests to me
that it's a matter of some bugs (and whether they are patched) than
any specific version number.  Is it again the same case: the test
detects a problem in an external library and the recommendation is
to install the patched build, and patching is more important than
the version number?  Shortly, is this anything we should deal with
as glibc or is the current behavior the best we want to provide?

Regards,

Rafal
Florian Weimer March 13, 2019, 9:10 p.m. UTC | #20
* 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
Florian Weimer March 13, 2019, 9:15 p.m. UTC | #21
* Rafal Luzynski:

> I have another issue which is little off-topic but also little
> similar. While playing with different Fedora releases I noticed
> that these two tests:
>
>     resolv/tst-resolv-ai_idn
>     resolv/tst-resolv-ai_idn-latin1
>
> may or may not fail depending on the version of libidn2 installed.

This is a regression in libidn2.  I'm working with libidn2 upstream to
get this fixed.  I will also contribute an execution trace from the
glibc tests to the libidn2 test suite once things settle upstream.  The
regressions raised some rather thorny questions regarding IDNA
compliance, so progress has been a bit slow.

My hope is that with the upstream test with the trace from glibc, future
regressions simply will not happen.

Thanks,
Florian
diff mbox series

Patch

diff --git a/elf/Makefile b/elf/Makefile
index faec577d1c..fbb159f9a6 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -326,23 +326,26 @@  tests-ifuncstatic := ifuncmain1static ifuncmain1picstatic \
 		ifuncmain2static ifuncmain2picstatic \
 		ifuncmain4static ifuncmain4picstatic \
 		ifuncmain5static ifuncmain5picstatic \
-		ifuncmain7static ifuncmain7picstatic
+		ifuncmain7static ifuncmain7picstatic \
+		ifuncmain9static ifuncmain9picstatic
 tests-static += $(tests-ifuncstatic)
 tests-internal += $(tests-ifuncstatic)
 ifeq (yes,$(build-shared))
+# Note: sysdeps/x86_64/ifuncmain8.c uses ifuncmain8.
 tests-internal += \
 	 ifuncmain1 ifuncmain1pic ifuncmain1vis ifuncmain1vispic \
 	 ifuncmain1staticpic \
 	 ifuncmain2 ifuncmain2pic ifuncmain3 ifuncmain4 \
 	 ifuncmain5 ifuncmain5pic ifuncmain5staticpic \
-	 ifuncmain7 ifuncmain7pic
+	 ifuncmain7 ifuncmain7pic \
+	 ifuncmain9 ifuncmain9pic
 ifunc-test-modules = ifuncdep1 ifuncdep1pic ifuncdep2 ifuncdep2pic \
 		     ifuncdep5 ifuncdep5pic
 extra-test-objs += $(ifunc-test-modules:=.o)
 test-internal-extras += $(ifunc-test-modules)
 ifeq (yes,$(have-fpie))
 ifunc-pie-tests = ifuncmain1pie ifuncmain1vispie ifuncmain1staticpie \
-		  ifuncmain5pie ifuncmain6pie ifuncmain7pie
+		  ifuncmain5pie ifuncmain6pie ifuncmain7pie ifuncmain9pie
 ifeq (yes,$(have-textrel_ifunc))
 ifunc-pie-tests += tst-ifunc-textrel
 endif
@@ -1276,6 +1279,8 @@  CFLAGS-ifuncmain5staticpic.c += $(pic-ccflag)
 CFLAGS-ifuncdep5pic.c += $(pic-ccflag)
 CFLAGS-ifuncmain7pic.c += $(pic-ccflag)
 CFLAGS-ifuncmain7picstatic.c += $(pic-ccflag)
+CFLAGS-ifuncmain9pic.c += $(pic-ccflag)
+CFLAGS-ifuncmain9picstatic.c += $(pic-ccflag)
 
 LDFLAGS-ifuncmain3 = -Wl,-export-dynamic
 
@@ -1285,6 +1290,7 @@  CFLAGS-ifuncmain1staticpie.c += $(pie-ccflag)
 CFLAGS-ifuncmain5pie.c += $(pie-ccflag)
 CFLAGS-ifuncmain6pie.c += $(pie-ccflag)
 CFLAGS-ifuncmain7pie.c += $(pie-ccflag)
+CFLAGS-ifuncmain9pie.c += $(pie-ccflag)
 CFLAGS-tst-ifunc-textrel.c += $(pic-ccflag)
 
 $(objpfx)ifuncmain1pie: $(objpfx)ifuncmod1.so
diff --git a/elf/ifuncmain9.c b/elf/ifuncmain9.c
new file mode 100644
index 0000000000..a8a9c49dd1
--- /dev/null
+++ b/elf/ifuncmain9.c
@@ -0,0 +1,107 @@ 
+/* Test for IFUNC handling with local definitions.
+   Copyright (C) 2019 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+/* This test is based on gcc.dg/attr-ifunc-4.c.  */
+
+#include <config.h>
+
+#ifdef HAVE_GCC_IFUNC
+
+# include <stdbool.h>
+# include <stdio.h>
+
+/* Do not use the test framework, so that the process setup is not
+   disturbed.  */
+
+static volatile int implementation_called;
+static volatile int resolver_called;
+
+/* Just a random constant, to check that we called the right
+   function.  */
+enum { random_constant = 0x3a88d66d };
+
+static int
+implementation (void)
+{
+  ++implementation_called;
+  return random_constant;
+}
+
+static __typeof__ (implementation) *
+resolver (void)
+{
+  ++resolver_called;
+  return implementation;
+}
+
+static int magic (void) __attribute__ ((ifunc ("resolver")));
+
+int
+main (void)
+{
+  bool errors = false;
+
+  if (implementation_called != 0)
+    {
+      printf ("error: initial value of implementation_called is not zero:"
+              " %d\n", implementation_called);
+      errors = true;
+    }
+
+  /* This can be zero if the reference is bound lazily.  */
+  printf ("info: initial value of resolver_called: %d\n", resolver_called);
+
+  int magic_value = magic ();
+  if (magic_value != random_constant)
+    {
+      printf ("error: invalid magic value: 0x%x\n", magic_value);
+      errors = true;
+    }
+
+  printf ("info: resolver_called value: %d\n", resolver_called);
+  if (resolver_called == 0)
+    {
+      /* In theory, the resolver could be called multiple times if
+         several relocations are needed.  */
+      puts ("error: invalid resolver_called value (must not be zero)");
+      errors = true;
+    }
+
+  printf ("info: implementation_called value: %d\n", implementation_called);
+  if (implementation_called != 1)
+    {
+      puts ("error: invalid implementation_called value (must be 1)");
+      errors = true;
+    }
+
+  return errors;
+}
+
+#else  /* !HAVE_GCC_IFUNC */
+
+# include <support/check.h>
+
+static int
+do_test (void)
+{
+  FAIL_UNSUPPORTED ("GCC does not support the ifunc attribute");
+  return 1;                     /* Not reachable.  */
+}
+
+# include <support/test-driver.c>
+#endif
diff --git a/elf/ifuncmain9pic.c b/elf/ifuncmain9pic.c
new file mode 100644
index 0000000000..6151a45e88
--- /dev/null
+++ b/elf/ifuncmain9pic.c
@@ -0,0 +1 @@ 
+#include "ifuncmain9.c"
diff --git a/elf/ifuncmain9picstatic.c b/elf/ifuncmain9picstatic.c
new file mode 100644
index 0000000000..6151a45e88
--- /dev/null
+++ b/elf/ifuncmain9picstatic.c
@@ -0,0 +1 @@ 
+#include "ifuncmain9.c"
diff --git a/elf/ifuncmain9pie.c b/elf/ifuncmain9pie.c
new file mode 100644
index 0000000000..6151a45e88
--- /dev/null
+++ b/elf/ifuncmain9pie.c
@@ -0,0 +1 @@ 
+#include "ifuncmain9.c"
diff --git a/elf/ifuncmain9static.c b/elf/ifuncmain9static.c
new file mode 100644
index 0000000000..6151a45e88
--- /dev/null
+++ b/elf/ifuncmain9static.c
@@ -0,0 +1 @@ 
+#include "ifuncmain9.c"