[2/2] Add a testcase for copy reloc against protected data
Commit Message
On Fri, Mar 6, 2015 at 11:09 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 5 Mar 2015, H.J. Lu wrote:
>
>> if test $libc_cv_visibility_attribute = yes; then
>> + AC_CACHE_CHECK(linker support for protected data symbol,
>> + libc_cv_protected_data,
>> + [cat > conftest.c <<EOF
>> + int bar __attribute__ ((visibility ("protected"))) = 1;
>> +EOF
>> + libc_cv_protected_data=no
>> + if AC_TRY_COMMAND(${CC-cc} -fPIC -shared conftest.c -o conftest.so); then
>
> Use -nostdlib -nostartfiles on all configure tests involving linking so
> that they work correctly in bootstrap configurations, unless there is a
> clear reason they cannot work with -nostdlib -nostartfiles (in which case
> there should be thorough comments about the issue).
>
>> + cat > conftest.c <<EOF
>> + extern int bar;
>> + int main (void) { return bar; }
>> +EOF
>> + if AC_TRY_COMMAND(${CC-cc} conftest.c -o conftest conftest.so); then
>
> Likewise; you may need to use -static as well (or LIBC_TRY_LINK_STATIC).
>
Done. Here is an updated patch.
> Suppose I configure / build with new binutils but a GCC version without
> your patches. What will the results be? That the tests don't build /
> run? That they build / run but fail (best avoided if possible)? In
> either case, you need clear documentation for architecture maintainers on
> what GCC versions (*not* requiring any uncommitted GCC patches) must be
> used to identify whether architecture-specific changes are needed and to
> test such changes.
>
I will submit a separate patch to address GCC issue.
Comments
On Fri, 6 Mar 2015, H.J. Lu wrote:
> > Suppose I configure / build with new binutils but a GCC version without
> > your patches. What will the results be? That the tests don't build /
> > run? That they build / run but fail (best avoided if possible)? In
> > either case, you need clear documentation for architecture maintainers on
> > what GCC versions (*not* requiring any uncommitted GCC patches) must be
> > used to identify whether architecture-specific changes are needed and to
> > test such changes.
> >
>
> I will submit a separate patch to address GCC issue.
I don't think these tests should go in glibc until:
(a) they work with some checked-in mainline GCC version (i.e., if they
need the GCC patches you posted, those are on GCC trunk);
(b) it's clear what GCC and binutils versions are needed for the tests to
work (e.g. "GCC 5 or later, trunk revision NNNNNN or later; binutils
commit 89abcdef or later").
On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 6 Mar 2015, H.J. Lu wrote:
>
>> > Suppose I configure / build with new binutils but a GCC version without
>> > your patches. What will the results be? That the tests don't build /
>> > run? That they build / run but fail (best avoided if possible)? In
>> > either case, you need clear documentation for architecture maintainers on
>> > what GCC versions (*not* requiring any uncommitted GCC patches) must be
>> > used to identify whether architecture-specific changes are needed and to
>> > test such changes.
>> >
>>
>> I will submit a separate patch to address GCC issue.
>
> I don't think these tests should go in glibc until:
Which tests were you talking about? My copy relocation
tests work with any GCC versions, with and without the fix
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
It also work with binutils master and released versions of
binutils. Only binutils 2.25 branch is broken, which I will
fix shortly. My patch includes a check for broken linker
and it skips those tests if linker is broken.
> (a) they work with some checked-in mainline GCC version (i.e., if they
> need the GCC patches you posted, those are on GCC trunk);
>
> (b) it's clear what GCC and binutils versions are needed for the tests to
> work (e.g. "GCC 5 or later, trunk revision NNNNNN or later; binutils
> commit 89abcdef or later").
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
On Fri, 6 Mar 2015, H.J. Lu wrote:
> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Fri, 6 Mar 2015, H.J. Lu wrote:
> >
> >> > Suppose I configure / build with new binutils but a GCC version without
> >> > your patches. What will the results be? That the tests don't build /
> >> > run? That they build / run but fail (best avoided if possible)? In
> >> > either case, you need clear documentation for architecture maintainers on
> >> > what GCC versions (*not* requiring any uncommitted GCC patches) must be
> >> > used to identify whether architecture-specific changes are needed and to
> >> > test such changes.
> >> >
> >>
> >> I will submit a separate patch to address GCC issue.
> >
> > I don't think these tests should go in glibc until:
>
> Which tests were you talking about? My copy relocation
> tests work with any GCC versions, with and without the fix
> for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
Thanks for the explanation. In
<https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
originally sent patches for all three of GCC, binutils, glibc, so giving
the impression there might be dependencies between these patches. If the
tests work with any GCC version (i.e. fail if the architecture hasn't been
fixed, pass if it has been fixed) then GCC changes shouldn't need to block
them.
On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 6 Mar 2015, H.J. Lu wrote:
>
>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> > On Fri, 6 Mar 2015, H.J. Lu wrote:
>> >
>> >> > Suppose I configure / build with new binutils but a GCC version without
>> >> > your patches. What will the results be? That the tests don't build /
>> >> > run? That they build / run but fail (best avoided if possible)? In
>> >> > either case, you need clear documentation for architecture maintainers on
>> >> > what GCC versions (*not* requiring any uncommitted GCC patches) must be
>> >> > used to identify whether architecture-specific changes are needed and to
>> >> > test such changes.
>> >> >
>> >>
>> >> I will submit a separate patch to address GCC issue.
>> >
>> > I don't think these tests should go in glibc until:
>>
>> Which tests were you talking about? My copy relocation
>> tests work with any GCC versions, with and without the fix
>> for
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>
> Thanks for the explanation. In
> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
> originally sent patches for all three of GCC, binutils, glibc, so giving
> the impression there might be dependencies between these patches. If the
> tests work with any GCC version (i.e. fail if the architecture hasn't been
> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
> them.
>
To get copy reloc against protected data symbol working, you
need to fix glibc, binutils and GCC. My glibc tests work around
the GCC bug so that you don't need the fixed GCC to build/test
glibc.
On Fri, Mar 6, 2015 at 3:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>
>>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>> > On Fri, 6 Mar 2015, H.J. Lu wrote:
>>> >
>>> >> > Suppose I configure / build with new binutils but a GCC version without
>>> >> > your patches. What will the results be? That the tests don't build /
>>> >> > run? That they build / run but fail (best avoided if possible)? In
>>> >> > either case, you need clear documentation for architecture maintainers on
>>> >> > what GCC versions (*not* requiring any uncommitted GCC patches) must be
>>> >> > used to identify whether architecture-specific changes are needed and to
>>> >> > test such changes.
>>> >> >
>>> >>
>>> >> I will submit a separate patch to address GCC issue.
>>> >
>>> > I don't think these tests should go in glibc until:
>>>
>>> Which tests were you talking about? My copy relocation
>>> tests work with any GCC versions, with and without the fix
>>> for
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>>
>> Thanks for the explanation. In
>> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
>> originally sent patches for all three of GCC, binutils, glibc, so giving
>> the impression there might be dependencies between these patches. If the
>> tests work with any GCC version (i.e. fail if the architecture hasn't been
>> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
>> them.
>>
>
> To get copy reloc against protected data symbol working, you
> need to fix glibc, binutils and GCC. My glibc tests work around
> the GCC bug so that you don't need the fixed GCC to build/test
> glibc.
I checked in my testcase patch. I didn't close
https://sourceware.org/bugzilla/show_bug.cgi?id=17711
since only x86 is fixed. To fix it on a target with copy reloc, you need to
properly handle ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA like
x86. You also need to fix linker if tests fail.
On 03/31/2015 08:26 AM, H.J. Lu wrote:
> On Fri, Mar 6, 2015 at 3:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>
>>>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>
>>>>>>> Suppose I configure / build with new binutils but a GCC version without
>>>>>>> your patches. What will the results be? That the tests don't build /
>>>>>>> run? That they build / run but fail (best avoided if possible)? In
>>>>>>> either case, you need clear documentation for architecture maintainers on
>>>>>>> what GCC versions (*not* requiring any uncommitted GCC patches) must be
>>>>>>> used to identify whether architecture-specific changes are needed and to
>>>>>>> test such changes.
>>>>>>>
>>>>>>
>>>>>> I will submit a separate patch to address GCC issue.
>>>>>
>>>>> I don't think these tests should go in glibc until:
>>>>
>>>> Which tests were you talking about? My copy relocation
>>>> tests work with any GCC versions, with and without the fix
>>>> for
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>>>
>>> Thanks for the explanation. In
>>> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
>>> originally sent patches for all three of GCC, binutils, glibc, so giving
>>> the impression there might be dependencies between these patches. If the
>>> tests work with any GCC version (i.e. fail if the architecture hasn't been
>>> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
>>> them.
>>>
>>
>> To get copy reloc against protected data symbol working, you
>> need to fix glibc, binutils and GCC. My glibc tests work around
>> the GCC bug so that you don't need the fixed GCC to build/test
>> glibc.
>
> I checked in my testcase patch. I didn't close
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>
> since only x86 is fixed. To fix it on a target with copy reloc, you need to
> properly handle ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA like
> x86. You also need to fix linker if tests fail.
>
I assume when you say x86 you mean all of the variants of that machine.
Your test fail for me on F21 x86_64 with gcc 4.9.2 and ld 2.24 (Fedora
versions). I haven't looked into this, but hopefully we'll get Fedora--
specific build bots up to help with this kind of testing.
XPASS: conform/ISO11/complex.h/conform
XPASS: conform/ISO11/stdalign.h/conform
XPASS: conform/ISO11/stdnoreturn.h/conform
FAIL: elf/tst-protected1a
FAIL: elf/tst-protected1b
UNRESOLVED: timezone/testdata/UTC
Summary of test results:
2 FAIL
2199 PASS
1 UNRESOLVED
189 XFAIL
3 XPASS
[carlos@koi build]$ cat glibc/elf/tst-protected1a.out
`protected1' in main and moda doesn't have same address
`protected3' in main and moda doesn't have same address
`protected1' in main doesn't have the updated value
`protected1' in moda has the wrong value
`protected3' in main doesn't have the updated value
`protected3' in main doesn't have the updated value
[carlos@koi build]$ cat glibc/elf/tst-protected1b.out
`protected3' in main and modb doesn't have same address
`protected3' in main doesn't have the updated value
What's wrong?
Cheers,
Carlos.
On Wed, Apr 1, 2015 at 12:51 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 03/31/2015 08:26 AM, H.J. Lu wrote:
>> On Fri, Mar 6, 2015 at 3:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>
>>>>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>>
>>>>>>>> Suppose I configure / build with new binutils but a GCC version without
>>>>>>>> your patches. What will the results be? That the tests don't build /
>>>>>>>> run? That they build / run but fail (best avoided if possible)? In
>>>>>>>> either case, you need clear documentation for architecture maintainers on
>>>>>>>> what GCC versions (*not* requiring any uncommitted GCC patches) must be
>>>>>>>> used to identify whether architecture-specific changes are needed and to
>>>>>>>> test such changes.
>>>>>>>>
>>>>>>>
>>>>>>> I will submit a separate patch to address GCC issue.
>>>>>>
>>>>>> I don't think these tests should go in glibc until:
>>>>>
>>>>> Which tests were you talking about? My copy relocation
>>>>> tests work with any GCC versions, with and without the fix
>>>>> for
>>>>>
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>>>>
>>>> Thanks for the explanation. In
>>>> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
>>>> originally sent patches for all three of GCC, binutils, glibc, so giving
>>>> the impression there might be dependencies between these patches. If the
>>>> tests work with any GCC version (i.e. fail if the architecture hasn't been
>>>> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
>>>> them.
>>>>
>>>
>>> To get copy reloc against protected data symbol working, you
>>> need to fix glibc, binutils and GCC. My glibc tests work around
>>> the GCC bug so that you don't need the fixed GCC to build/test
>>> glibc.
>>
>> I checked in my testcase patch. I didn't close
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>>
>> since only x86 is fixed. To fix it on a target with copy reloc, you need to
>> properly handle ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA like
>> x86. You also need to fix linker if tests fail.
>>
>
> I assume when you say x86 you mean all of the variants of that machine.
>
> Your test fail for me on F21 x86_64 with gcc 4.9.2 and ld 2.24 (Fedora
> versions). I haven't looked into this, but hopefully we'll get Fedora--
> specific build bots up to help with this kind of testing.
>
> XPASS: conform/ISO11/complex.h/conform
> XPASS: conform/ISO11/stdalign.h/conform
> XPASS: conform/ISO11/stdnoreturn.h/conform
> FAIL: elf/tst-protected1a
> FAIL: elf/tst-protected1b
> UNRESOLVED: timezone/testdata/UTC
> Summary of test results:
> 2 FAIL
> 2199 PASS
> 1 UNRESOLVED
> 189 XFAIL
> 3 XPASS
>
> [carlos@koi build]$ cat glibc/elf/tst-protected1a.out
> `protected1' in main and moda doesn't have same address
> `protected3' in main and moda doesn't have same address
> `protected1' in main doesn't have the updated value
> `protected1' in moda has the wrong value
> `protected3' in main doesn't have the updated value
> `protected3' in main doesn't have the updated value
> [carlos@koi build]$ cat glibc/elf/tst-protected1b.out
> `protected3' in main and modb doesn't have same address
> `protected3' in main doesn't have the updated value
>
> What's wrong?
>
Linker bug. You need linker from master or 2.25 branch.
On 04/01/2015 03:55 PM, H.J. Lu wrote:
> On Wed, Apr 1, 2015 at 12:51 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 03/31/2015 08:26 AM, H.J. Lu wrote:
>>> On Fri, Mar 6, 2015 at 3:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>
>>>>>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>>>
>>>>>>>>> Suppose I configure / build with new binutils but a GCC version without
>>>>>>>>> your patches. What will the results be? That the tests don't build /
>>>>>>>>> run? That they build / run but fail (best avoided if possible)? In
>>>>>>>>> either case, you need clear documentation for architecture maintainers on
>>>>>>>>> what GCC versions (*not* requiring any uncommitted GCC patches) must be
>>>>>>>>> used to identify whether architecture-specific changes are needed and to
>>>>>>>>> test such changes.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I will submit a separate patch to address GCC issue.
>>>>>>>
>>>>>>> I don't think these tests should go in glibc until:
>>>>>>
>>>>>> Which tests were you talking about? My copy relocation
>>>>>> tests work with any GCC versions, with and without the fix
>>>>>> for
>>>>>>
>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>>>>>
>>>>> Thanks for the explanation. In
>>>>> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
>>>>> originally sent patches for all three of GCC, binutils, glibc, so giving
>>>>> the impression there might be dependencies between these patches. If the
>>>>> tests work with any GCC version (i.e. fail if the architecture hasn't been
>>>>> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
>>>>> them.
>>>>>
>>>>
>>>> To get copy reloc against protected data symbol working, you
>>>> need to fix glibc, binutils and GCC. My glibc tests work around
>>>> the GCC bug so that you don't need the fixed GCC to build/test
>>>> glibc.
>>>
>>> I checked in my testcase patch. I didn't close
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>>>
>>> since only x86 is fixed. To fix it on a target with copy reloc, you need to
>>> properly handle ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA like
>>> x86. You also need to fix linker if tests fail.
>>>
>>
>> I assume when you say x86 you mean all of the variants of that machine.
>>
>> Your test fail for me on F21 x86_64 with gcc 4.9.2 and ld 2.24 (Fedora
>> versions). I haven't looked into this, but hopefully we'll get Fedora--
>> specific build bots up to help with this kind of testing.
>>
>> XPASS: conform/ISO11/complex.h/conform
>> XPASS: conform/ISO11/stdalign.h/conform
>> XPASS: conform/ISO11/stdnoreturn.h/conform
>> FAIL: elf/tst-protected1a
>> FAIL: elf/tst-protected1b
>> UNRESOLVED: timezone/testdata/UTC
>> Summary of test results:
>> 2 FAIL
>> 2199 PASS
>> 1 UNRESOLVED
>> 189 XFAIL
>> 3 XPASS
>>
>> [carlos@koi build]$ cat glibc/elf/tst-protected1a.out
>> `protected1' in main and moda doesn't have same address
>> `protected3' in main and moda doesn't have same address
>> `protected1' in main doesn't have the updated value
>> `protected1' in moda has the wrong value
>> `protected3' in main doesn't have the updated value
>> `protected3' in main doesn't have the updated value
>> [carlos@koi build]$ cat glibc/elf/tst-protected1b.out
>> `protected3' in main and modb doesn't have same address
>> `protected3' in main doesn't have the updated value
>>
>> What's wrong?
>>
>
> Linker bug. You need linker from master or 2.25 branch.
Please mention this in the build and test issues for 2.22:
https://sourceware.org/glibc/wiki/Release/2.22#Build_and_test_issues
Cheers,
Carlos.
On Wed, Apr 1, 2015 at 1:31 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 04/01/2015 03:55 PM, H.J. Lu wrote:
>> On Wed, Apr 1, 2015 at 12:51 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 03/31/2015 08:26 AM, H.J. Lu wrote:
>>>> On Fri, Mar 6, 2015 at 3:24 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Mar 6, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>>
>>>>>>> On Fri, Mar 6, 2015 at 2:23 PM, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>>>> On Fri, 6 Mar 2015, H.J. Lu wrote:
>>>>>>>>
>>>>>>>>>> Suppose I configure / build with new binutils but a GCC version without
>>>>>>>>>> your patches. What will the results be? That the tests don't build /
>>>>>>>>>> run? That they build / run but fail (best avoided if possible)? In
>>>>>>>>>> either case, you need clear documentation for architecture maintainers on
>>>>>>>>>> what GCC versions (*not* requiring any uncommitted GCC patches) must be
>>>>>>>>>> used to identify whether architecture-specific changes are needed and to
>>>>>>>>>> test such changes.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will submit a separate patch to address GCC issue.
>>>>>>>>
>>>>>>>> I don't think these tests should go in glibc until:
>>>>>>>
>>>>>>> Which tests were you talking about? My copy relocation
>>>>>>> tests work with any GCC versions, with and without the fix
>>>>>>> for
>>>>>>>
>>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
>>>>>>
>>>>>> Thanks for the explanation. In
>>>>>> <https://sourceware.org/ml/libc-alpha/2015-03/msg00170.html> you
>>>>>> originally sent patches for all three of GCC, binutils, glibc, so giving
>>>>>> the impression there might be dependencies between these patches. If the
>>>>>> tests work with any GCC version (i.e. fail if the architecture hasn't been
>>>>>> fixed, pass if it has been fixed) then GCC changes shouldn't need to block
>>>>>> them.
>>>>>>
>>>>>
>>>>> To get copy reloc against protected data symbol working, you
>>>>> need to fix glibc, binutils and GCC. My glibc tests work around
>>>>> the GCC bug so that you don't need the fixed GCC to build/test
>>>>> glibc.
>>>>
>>>> I checked in my testcase patch. I didn't close
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17711
>>>>
>>>> since only x86 is fixed. To fix it on a target with copy reloc, you need to
>>>> properly handle ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA like
>>>> x86. You also need to fix linker if tests fail.
>>>>
>>>
>>> I assume when you say x86 you mean all of the variants of that machine.
>>>
>>> Your test fail for me on F21 x86_64 with gcc 4.9.2 and ld 2.24 (Fedora
>>> versions). I haven't looked into this, but hopefully we'll get Fedora--
>>> specific build bots up to help with this kind of testing.
>>>
>>> XPASS: conform/ISO11/complex.h/conform
>>> XPASS: conform/ISO11/stdalign.h/conform
>>> XPASS: conform/ISO11/stdnoreturn.h/conform
>>> FAIL: elf/tst-protected1a
>>> FAIL: elf/tst-protected1b
>>> UNRESOLVED: timezone/testdata/UTC
>>> Summary of test results:
>>> 2 FAIL
>>> 2199 PASS
>>> 1 UNRESOLVED
>>> 189 XFAIL
>>> 3 XPASS
>>>
>>> [carlos@koi build]$ cat glibc/elf/tst-protected1a.out
>>> `protected1' in main and moda doesn't have same address
>>> `protected3' in main and moda doesn't have same address
>>> `protected1' in main doesn't have the updated value
>>> `protected1' in moda has the wrong value
>>> `protected3' in main doesn't have the updated value
>>> `protected3' in main doesn't have the updated value
>>> [carlos@koi build]$ cat glibc/elf/tst-protected1b.out
>>> `protected3' in main and modb doesn't have same address
>>> `protected3' in main doesn't have the updated value
>>>
>>> What's wrong?
>>>
>>
>> Linker bug. You need linker from master or 2.25 branch.
>
> Please mention this in the build and test issues for 2.22:
>
> https://sourceware.org/glibc/wiki/Release/2.22#Build_and_test_issues
>
Done.
From ab16864ad041c68a3ae514fc1e9b62e69a037ea2 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Thu, 5 Mar 2015 11:36:35 -0800
Subject: [PATCH 2/3] Add a testcase for copy reloc against protected data
Linkers in some versions of binutils 2.25 and 2.26 don't support protected
data symbol with error messsage like:
/usr/bin/ld: copy reloc against protected `bar' is invalid
/usr/bin/ld: failed to set dynamic section sizes: Bad value
We check if linker supports copy reloc against protected data symbol to
avoid running the test if linker is broken.
[BZ #17711]
* config.make.in (have-protected-data): New.
* configure.ac: Check linker support for protected data symbol.
* configure: Regenerated.
* elf/Makefile (modules-names): Add tst-protected1moda and
tst-protected1modb if $(have-protected-data) is yes.
(tests): Add tst-protected1a and tst-protected1b if
$(have-protected-data) is yes.
($(objpfx)tst-protected1a): New.
($(objpfx)tst-protected1b): Likewise.
(tst-protected1modb.so-no-z-defs): Likewise.
* elf/tst-protected1a.c: New file.
* elf/tst-protected1b.c: Likewise.
* elf/tst-protected1mod.h: Likewise.
* elf/tst-protected1moda.c: Likewise.
* elf/tst-protected1modb.c: Likewise.
---
config.make.in | 1 +
configure | 40 +++++++++++++
configure.ac | 23 +++++++
elf/Makefile | 7 +++
elf/tst-protected1a.c | 153 +++++++++++++++++++++++++++++++++++++++++++++++
elf/tst-protected1b.c | 152 ++++++++++++++++++++++++++++++++++++++++++++++
elf/tst-protected1mod.h | 31 ++++++++++
elf/tst-protected1moda.c | 64 ++++++++++++++++++++
elf/tst-protected1modb.c | 33 ++++++++++
9 files changed, 504 insertions(+)
create mode 100644 elf/tst-protected1a.c
create mode 100644 elf/tst-protected1b.c
create mode 100644 elf/tst-protected1mod.h
create mode 100644 elf/tst-protected1moda.c
create mode 100644 elf/tst-protected1modb.c
@@ -50,6 +50,7 @@ enable-werror = @enable_werror@
have-z-combreloc = @libc_cv_z_combreloc@
have-z-execstack = @libc_cv_z_execstack@
have-Bgroup = @libc_cv_Bgroup@
+have-protected-data = @libc_cv_protected_data@
with-fp = @with_fp@
old-glibc-headers = @old_glibc_headers@
unwind-find-fde = @libc_cv_gcc_unwind_find_fde@
@@ -634,6 +634,7 @@ libc_cv_z_combreloc
ASFLAGS_config
libc_cv_Bgroup
libc_cv_cc_with_libunwind
+libc_cv_protected_data
BISON
INSTALL_INFO
PERL
@@ -5734,6 +5735,45 @@ $as_echo "$libc_cv_visibility_attribute" >&6; }
fi
if test $libc_cv_visibility_attribute = yes; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking linker support for protected data symbol" >&5
+$as_echo_n "checking linker support for protected data symbol... " >&6; }
+if ${libc_cv_protected_data+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ cat > conftest.c <<EOF
+ int bar __attribute__ ((visibility ("protected"))) = 1;
+EOF
+ libc_cv_protected_data=no
+ if { ac_try='${CC-cc} -nostdlib -nostartfiles -fPIC -shared conftest.c -o conftest.so'
+ { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }; then
+ cat > conftest.c <<EOF
+ extern int bar;
+ int main (void) { return bar; }
+EOF
+ if { ac_try='${CC-cc} -nostdlib -nostartfiles conftest.c -o conftest conftest.so'
+ { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }; then
+ libc_cv_protected_data=yes
+ fi
+ fi
+ rm -f conftest.*
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_protected_data" >&5
+$as_echo "$libc_cv_protected_data" >&6; }
+else
+ libc_cv_protected_data=no
+fi
+
+
+if test $libc_cv_visibility_attribute = yes; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for broken __attribute__((visibility()))" >&5
$as_echo_n "checking for broken __attribute__((visibility()))... " >&6; }
if ${libc_cv_broken_visibility_attribute+:} false; then :
@@ -1220,6 +1220,29 @@ EOF
fi
if test $libc_cv_visibility_attribute = yes; then
+ AC_CACHE_CHECK(linker support for protected data symbol,
+ libc_cv_protected_data,
+ [cat > conftest.c <<EOF
+ int bar __attribute__ ((visibility ("protected"))) = 1;
+EOF
+ libc_cv_protected_data=no
+ if AC_TRY_COMMAND(${CC-cc} -nostdlib -nostartfiles -fPIC -shared conftest.c -o conftest.so); then
+ cat > conftest.c <<EOF
+ extern int bar;
+ int main (void) { return bar; }
+EOF
+ if AC_TRY_COMMAND(${CC-cc} -nostdlib -nostartfiles conftest.c -o conftest conftest.so); then
+ libc_cv_protected_data=yes
+ fi
+ fi
+ rm -f conftest.*
+ ])
+else
+ libc_cv_protected_data=no
+fi
+AC_SUBST(libc_cv_protected_data)
+
+if test $libc_cv_visibility_attribute = yes; then
AC_CACHE_CHECK(for broken __attribute__((visibility())),
libc_cv_broken_visibility_attribute,
[cat > conftest.c <<EOF
@@ -213,6 +213,13 @@ modules-names = testobj1 testobj2 testobj3 testobj4 testobj5 testobj6 \
tst-initorder2d \
tst-relsort1mod1 tst-relsort1mod2 tst-array2dep \
tst-array5dep tst-null-argv-lib
+ifeq (yes,$(have-protected-data))
+modules-names += tst-protected1moda tst-protected1modb
+tests += tst-protected1a tst-protected1b
+$(objpfx)tst-protected1a: $(addprefix $(objpfx),tst-protected1moda.so tst-protected1modb.so)
+$(objpfx)tst-protected1b: $(addprefix $(objpfx),tst-protected1modb.so tst-protected1moda.so)
+tst-protected1modb.so-no-z-defs = yes
+endif
ifeq (yesyes,$(have-fpie)$(build-shared))
modules-names += tst-piemod1
tests += tst-pie1 tst-pie2
new file mode 100644
@@ -0,0 +1,153 @@
+/* Test the protected visibility when main is linked with moda and modb
+ in that order:
+ 1. Protected symbols, protected1 and protected2, defined in moda, are
+ used in moda.
+ 2. Symbol, protected1, defined in moda, is also used in main and modb.
+ 3. Symbol, protected2, defined in main, is used in main.
+
+ Copyright (C) 2015 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 file must be compiled as PIE to avoid copy relocation when
+ accessing protected symbols defined in shared libaries since copy
+ relocation doesn't work with protected symbols and linker in
+ binutils 2.26 enforces this rule. */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include "tst-protected1mod.h"
+
+/* Prototype for our test function. */
+extern int do_test (void);
+
+int protected2 = -1;
+
+#define TEST_FUNCTION do_test ()
+
+/* This defines the `main' function and some more. */
+#include <test-skeleton.c>
+
+int
+do_test (void)
+{
+ int res = 0;
+
+ /* Check if we get the same address for the protected data symbol. */
+ if (&protected1 != protected1a_p ())
+ {
+ puts ("`protected1' in main and moda doesn't have same address");
+ res = 1;
+ }
+ if (&protected1 != protected1b_p ())
+ {
+ puts ("`protected1' in main and modb doesn't have same address");
+ res = 1;
+ }
+
+ /* Check if we get the right value for the protected data symbol. */
+ if (protected1 != 3)
+ {
+ puts ("`protected1' in main and moda doesn't have same value");
+ res = 1;
+ }
+
+ /* Check if we get the right value for data defined in executable. */
+ if (protected2 != -1)
+ {
+ puts ("`protected2' in main has the wrong value");
+ res = 1;
+ }
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Set `protected2' in moda to 30. */
+ set_protected2 (300);
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Set `protected1' in moda to 30. */
+ set_protected1a (30);
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if we get the updated value for the protected data symbol. */
+ if (protected1 != 30)
+ {
+ puts ("`protected1' in main doesn't have the updated value");
+ res = 1;
+ }
+
+ protected2 = -300;
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if data defined in executable is changed. */
+ if (protected2 != -300)
+ {
+ puts ("`protected2' in main is changed");
+ res = 1;
+ }
+
+ /* Set `protected1' in modb to 40. */
+ set_protected1b (40);
+ set_expected_protected1 (40);
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if we get the updated value for the protected data symbol. */
+ if (protected1 != 40)
+ {
+ puts ("`protected1' in main doesn't have the updated value");
+ res = 1;
+ }
+
+ return res;
+}
new file mode 100644
@@ -0,0 +1,152 @@
+/* Test the protected visibility when main is linked with modb and moda
+ in that order:
+ 1. Protected symbols, protected1 and protected2, defined in moda, are
+ used in moda.
+ 2. Symbol, protected1, defined in modb, is used in main and modb.
+ 3. Symbol, protected2, defined in main, is used in main.
+
+ Copyright (C) 2015 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 file must be compiled as PIE to avoid copy relocation when
+ accessing protected symbols defined in shared libaries since copy
+ relocation doesn't work with protected symbols and linker in
+ binutils 2.26 enforces this rule. */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include "tst-protected1mod.h"
+
+/* Prototype for our test function. */
+extern int do_test (void);
+
+int protected2 = -1;
+
+#define TEST_FUNCTION do_test ()
+
+/* This defines the `main' function and some more. */
+#include <test-skeleton.c>
+
+int
+do_test (void)
+{
+ int res = 0;
+
+ /* Check if we get the same address for the protected data symbol. */
+ if (&protected1 == protected1a_p ())
+ {
+ puts ("`protected1' in main and moda has same address");
+ res = 1;
+ }
+ if (&protected1 != protected1b_p ())
+ {
+ puts ("`protected1' in main and modb doesn't have same address");
+ res = 1;
+ }
+
+ /* Check if we get the right value for the protected data symbol. */
+ if (protected1 != -3)
+ {
+ puts ("`protected1' in main and modb doesn't have same value");
+ res = 1;
+ }
+
+ /* Check if we get the right value for data defined in executable. */
+ if (protected2 != -1)
+ {
+ puts ("`protected2' in main has the wrong value");
+ res = 1;
+ }
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Set `protected2' in moda to 30. */
+ set_protected2 (300);
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Set `protected1' in moda to 30. */
+ set_protected1a (30);
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if we get the same value for the protected data symbol. */
+ if (protected1 != -3)
+ {
+ puts ("`protected1' in main has the wrong value");
+ res = 1;
+ }
+
+ protected2 = -300;
+
+ /* Check `protected2' in moda. */
+ if (!check_protected2 ())
+ {
+ puts ("`protected2' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if data defined in executable is changed. */
+ if (protected2 != -300)
+ {
+ puts ("`protected2' in main is changed");
+ res = 1;
+ }
+
+ /* Set `protected1' in modb to 40. */
+ set_protected1b (40);
+
+ /* Check `protected1' in moda. */
+ if (!check_protected1 ())
+ {
+ puts ("`protected1' in moda has the wrong value");
+ res = 1;
+ }
+
+ /* Check if we get the updated value for the protected data symbol. */
+ if (protected1 != 40)
+ {
+ puts ("`protected1' in main doesn't have the updated value");
+ res = 1;
+ }
+
+ return res;
+}
new file mode 100644
@@ -0,0 +1,31 @@
+/* Copyright (C) 2015 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/>. */
+
+/* Prototypes for the functions in the DSOs. */
+extern int protected1;
+extern int protected2;
+
+extern void set_protected1a (int);
+extern void set_protected1b (int);
+extern int *protected1a_p (void);
+extern int *protected1b_p (void);
+
+extern void set_expected_protected1 (int);
+extern int check_protected1 (void);
+
+extern void set_protected2 (int);
+extern int check_protected2 (void);
new file mode 100644
@@ -0,0 +1,64 @@
+/* Copyright (C) 2015 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/>. */
+
+#include "tst-protected1mod.h"
+
+int protected1 = 3;
+static int expected_protected1 = 3;
+int protected2 = 4;
+static int expected_protected2 = 4;
+
+asm (".protected protected1");
+asm (".protected protected2");
+
+void
+set_protected1a (int i)
+{
+ protected1 = i;
+ set_expected_protected1 (i);
+}
+
+void
+set_expected_protected1 (int i)
+{
+ expected_protected1 = i;
+}
+
+int *
+protected1a_p (void)
+{
+ return &protected1;
+}
+
+int
+check_protected1 (void)
+{
+ return protected1 == expected_protected1;
+}
+
+void
+set_protected2 (int i)
+{
+ protected2 = i;
+ expected_protected2 = i;
+}
+
+int
+check_protected2 (void)
+{
+ return protected2 == expected_protected2;
+}
new file mode 100644
@@ -0,0 +1,33 @@
+/* Copyright (C) 2015 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/>. */
+
+#include <stdlib.h>
+#include "tst-protected1mod.h"
+
+int protected1 = -3;
+
+void
+set_protected1b (int i)
+{
+ protected1 = i;
+}
+
+int *
+protected1b_p (void)
+{
+ return &protected1;
+}
--
1.9.3