[v2,0/4] PowerPC64 static-pie

  This is a repost of the series at
https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
incorporating review comments.

Changes are:
- subject lines changed to comply with glibc commit log standards
- patch 1/4 log now mentions making a couple of symbols hidden
- patch 2/4 makes at_platform available to early ifunc resolvers
  as well as hwcap.
- patch 3/4 log mentions stinfo->init and stinfo->fini being unused
- patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on

patch 2/4 is the only code change from the previous series.  Testsuite
results now show no regressions on powerpc64le-linux.

I haven't reposted the old patch 4/5 as it was just a side-issue I
noticed when looking over relative relocations.
https://sourceware.org/pipermail/libc-alpha/2022-January/135603.html 
I think it qualifies as an obvious patch so will commit it separately
from this series.

Alan Modra (4):
  powerpc64: Use medium model toc accesses throughout
  powerpc64: Set up thread register for _dl_relocate_static_pie
  powerpc: Relocate stinfo->main
  powerpc64: Enable static-pie

 sysdeps/powerpc/hwcapinfo.c                  |  8 ++---
 sysdeps/powerpc/hwcapinfo.h                  |  3 +-
 sysdeps/powerpc/nptl/tls.h                   |  8 ++---
 sysdeps/powerpc/powerpc64/__longjmp-common.S |  8 +++--
 sysdeps/powerpc/powerpc64/configure          |  6 ++++
 sysdeps/powerpc/powerpc64/configure.ac       |  9 ++++++
 sysdeps/powerpc/powerpc64/dl-machine.h       | 33 +++++++++++++++++---
 sysdeps/powerpc/powerpc64/dl-trampoline.S    |  8 +++--
 sysdeps/powerpc/powerpc64/setjmp-common.S    |  8 +++--
 sysdeps/powerpc/powerpc64/start.S            |  3 +-
 sysdeps/powerpc/powerpc64/sysdep.h           |  6 ++--
 sysdeps/unix/sysv/linux/powerpc/Makefile     |  6 ++++
 sysdeps/unix/sysv/linux/powerpc/libc-start.c | 15 +++++++--
 13 files changed, 93 insertions(+), 28 deletions(-)
  

On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote:
> This is a repost of the series at
> https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
> incorporating review comments.

I neglected to say that this series was tested powerpc64le-linux
showing no regressions.  I also tested powerpc64-linux today, both
static-pie and dt_relr no regressions.  (Well, there were 3 tests that
regressed, but passed when run by hand.  Probably some sort of
resource starvation.)
  

On Fri, Mar 04, 2022 at 11:18:10PM +1030, Alan Modra wrote:
> On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote:
> > This is a repost of the series at
> > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
> > incorporating review comments.
> 
> I neglected to say that this series was tested powerpc64le-linux
> showing no regressions.  I also tested powerpc64-linux today, both
> static-pie and dt_relr no regressions.  (Well, there were 3 tests that
> regressed, but passed when run by hand.  Probably some sort of
> resource starvation.)

Ping.

https://sourceware.org/pipermail/libc-alpha/2022-February/136727.html
  

Alan Modra via Libc-alpha <libc-alpha@sourceware.org> writes:

> This is a repost of the series at
> https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
> incorporating review comments.
>
> Changes are:
> - subject lines changed to comply with glibc commit log standards
> - patch 1/4 log now mentions making a couple of symbols hidden
> - patch 2/4 makes at_platform available to early ifunc resolvers
>   as well as hwcap.
> - patch 3/4 log mentions stinfo->init and stinfo->fini being unused
> - patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on
>
> patch 2/4 is the only code change from the previous series.  Testsuite
> results now show no regressions on powerpc64le-linux.

I'm still seeing the following failures on powerpc64le-linux:

FAIL: elf/tst-tls1-static-non-pie
FAIL: gmon/tst-gmon-static
FAIL: gmon/tst-gmon-static-gprof

Am I missing anything?
I used different GCC and Binutils versions ranging between:
 - GCC v8 and v11
 - Binutils 2.30 and 2.38 (2020-03-04)

Anyway, this is a summary of what I think about these patches:

- Patch 1: Looks good to me.
- Patch 2: Looks good to me.
- Patch 3: Looks good to me after a minor change.
- Patch 4: Hopefully I'm just missing a detail. Otherwise, I believe we should
           delay it until the previous issues are fixed.

Let me elaborate this replying to each patch.
  

On 2022-04-08, Alan Modra via Libc-alpha wrote:
>On Fri, Mar 04, 2022 at 11:18:10PM +1030, Alan Modra wrote:
>> On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote:
>> > This is a repost of the series at
>> > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
>> > incorporating review comments.
>>
>> I neglected to say that this series was tested powerpc64le-linux
>> showing no regressions.  I also tested powerpc64-linux today, both
>> static-pie and dt_relr no regressions.  (Well, there were 3 tests that
>> regressed, but passed when run by hand.  Probably some sort of
>> resource starvation.)
>
>Ping.
>
>https://sourceware.org/pipermail/libc-alpha/2022-February/136727.html

HJ's DT_RELR patch series has been upgraded to v7
(https://patchwork.sourceware.org/project/glibc/list/?series=8295)

   git-pw series apply 8295
   # `Add --disable-default-dt-relr` does not apply cleanly

If no regressions with default DT_RELR, that will be cool!
  

On Fri, Apr 08, 2022 at 07:27:32PM -0300, Tulio Magno Quites Machado Filho wrote:
> Alan Modra via Libc-alpha <libc-alpha@sourceware.org> writes:
> 
> > This is a repost of the series at
> > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html
> > incorporating review comments.
> >
> > Changes are:
> > - subject lines changed to comply with glibc commit log standards
> > - patch 1/4 log now mentions making a couple of symbols hidden
> > - patch 2/4 makes at_platform available to early ifunc resolvers
> >   as well as hwcap.
> > - patch 3/4 log mentions stinfo->init and stinfo->fini being unused
> > - patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on
> >
> > patch 2/4 is the only code change from the previous series.  Testsuite
> > results now show no regressions on powerpc64le-linux.
> 
> I'm still seeing the following failures on powerpc64le-linux:
> 
> FAIL: elf/tst-tls1-static-non-pie
> FAIL: gmon/tst-gmon-static
> FAIL: gmon/tst-gmon-static-gprof
> 
> Am I missing anything?
> 
> I used different GCC and Binutils versions ranging between:
>  - GCC v8 and v11
>  - Binutils 2.30 and 2.38 (2020-03-04)

I was testing with mainline binutils and gcc (gcc-12 20220122).  It is
quite likeley that bleeding edge tools are required for static-pie on
ppc64le.  I'll see if I can recreate some of your results, in
particular with 2.38 binutils.  Mainline ppc64 binutils has a patch
that changes linker behaviour for absolute symbols.  I haven't
backported that patch, or the DT_RELR support, to the 2.38 branch
because those changes might result in breakage.  I'd rather let them
mature a while on mainline.

Here are the results I was seeing with both static-pie and relr
support enabled for ppc64 vs. basline glibc.  Same toolchain for both
glibc builds.

--- base_results   2022-03-04 04:36:09.71152949 -0600
+++ staticpierelr_results   2022-03-04 04:36:17.263676034 -0600
@@ -24,7 +24,7 @@
 UNSUPPORTED: time/tst-settimeofday
 Summary of test results:
       3 FAIL
-   4798 PASS
+   4802 PASS
      19 UNSUPPORTED
      16 XFAIL
       2 XPASS

The three fails common to both test runs were
FAIL: math/test-ibm128-llround
FAIL: math/test-ibm128-y1
FAIL: nptl/tst-pthread-gdb-attach-static
The extra PASSes are new DT_RELR tests I think.

> Anyway, this is a summary of what I think about these patches:
> 
> - Patch 1: Looks good to me.
> - Patch 2: Looks good to me.
> - Patch 3: Looks good to me after a minor change.
> - Patch 4: Hopefully I'm just missing a detail. Otherwise, I believe we should
>            delay it until the previous issues are fixed.

Thanks, I'm happy to leave out patch 4 for the time being, and perhaps
change it so that --enable-static-pie on the configure line is needed
for ppc64.

First three pushed along with the dl_vdso_vsym tweak, but I did see
this weird warning, whatever that means..

alan@squeak:~/src/glibc-current$ git push origin 1a85970f41ea1e5abe6da2298a5e8fedcea26b70:master
Enumerating objects: 62, done.
Counting objects: 100% (62/62), done.
Delta compression using up to 32 threads
Compressing objects: 100% (37/37), done.
Writing objects: 100% (39/39), 6.06 KiB | 6.06 MiB/s, done.
Total 39 (delta 33), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File "/usr/local/bin/irkerhook.py", line 545, in <module>
remote:     ship(extractor, commit, not notify)
remote:   File "/usr/local/bin/irkerhook.py", line 467, in ship
remote:     privmsg = unicode(metadata)
remote:   File "/usr/local/bin/irkerhook.py", line 99, in __unicode__
remote:     if e.code == 401:
remote: AttributeError: 'URLError' object has no attribute 'code'
remote: *** !!! WARNING: /git/glibc.git/hooks-bin/post-receive returned code: 1.
To ssh://sourceware.org/git/glibc.git
   c0efbf8920..1a85970f41  1a85970f41ea1e5abe6da2298a5e8fedcea26b70 -> master
  

On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote:
> HJ's DT_RELR patch series has been upgraded to v7
> (https://patchwork.sourceware.org/project/glibc/list/?series=8295)
> 
>   git-pw series apply 8295
>   # `Add --disable-default-dt-relr` does not apply cleanly
> 
> If no regressions with default DT_RELR, that will be cool!

I did find one error when testing a build of glibc using Ubuntu gcc-8.
elf/filter fails with "error while loading shared libraries:
.../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency".

A little analysis shows the problem occurs when filtmod1.so is linked
with --as-needed and libc.so is not needed.  filtmod1.so ends up with
no .gnu.version or .gnu.version_r sections, and of course no
GLIBC_ABI_DT_RELR version.

The error check is not one that belongs in ld.so.  If you have the
error checking code, then you have DT_RELR support in ld.so and there
is no reason at all to refuse to run the program!  The check should be
in the linker, if anywhere.
  

On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote:
> > HJ's DT_RELR patch series has been upgraded to v7
> > (https://patchwork.sourceware.org/project/glibc/list/?series=8295)
> >
> >   git-pw series apply 8295
> >   # `Add --disable-default-dt-relr` does not apply cleanly
> >
> > If no regressions with default DT_RELR, that will be cool!
>
> I did find one error when testing a build of glibc using Ubuntu gcc-8.
> elf/filter fails with "error while loading shared libraries:
> .../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency".
>
> A little analysis shows the problem occurs when filtmod1.so is linked
> with --as-needed and libc.so is not needed.  filtmod1.so ends up with
> no .gnu.version or .gnu.version_r sections, and of course no
> GLIBC_ABI_DT_RELR version.
>
> The error check is not one that belongs in ld.so.  If you have the
> error checking code, then you have DT_RELR support in ld.so and there
> is no reason at all to refuse to run the program!  The check should be
> in the linker, if anywhere.
>

The GLIBC_ABI_DT_RELR dependency is added to avoid the random
crush at run-time with older glibc binaries.   Since it is possible to create
a DSO with DT_RELR, but without the libc.so dependency.   Should ld.so
skip the GLIBC_ABI_DT_RELR check if the DSO doesn't depend on
libc.so?
  

On 2022-04-13, H.J. Lu wrote:
>On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> wrote:
>>
>> On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote:
>> > HJ's DT_RELR patch series has been upgraded to v7
>> > (https://patchwork.sourceware.org/project/glibc/list/?series=8295)
>> >
>> >   git-pw series apply 8295
>> >   # `Add --disable-default-dt-relr` does not apply cleanly
>> >
>> > If no regressions with default DT_RELR, that will be cool!
>>
>> I did find one error when testing a build of glibc using Ubuntu gcc-8.
>> elf/filter fails with "error while loading shared libraries:
>> .../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency".
>>
>> A little analysis shows the problem occurs when filtmod1.so is linked
>> with --as-needed and libc.so is not needed.  filtmod1.so ends up with
>> no .gnu.version or .gnu.version_r sections, and of course no
>> GLIBC_ABI_DT_RELR version.
>>
>> The error check is not one that belongs in ld.so.  If you have the
>> error checking code, then you have DT_RELR support in ld.so and there
>> is no reason at all to refuse to run the program!  The check should be
>> in the linker, if anywhere.
>>
>
>The GLIBC_ABI_DT_RELR dependency is added to avoid the random
>crush at run-time with older glibc binaries.   Since it is possible to create
>a DSO with DT_RELR, but without the libc.so dependency.   Should ld.so
>skip the GLIBC_ABI_DT_RELR check if the DSO doesn't depend on
>libc.so?

Looks good.
  

On Wed, Apr 13, 2022 at 06:54:17PM -0700, H.J. Lu wrote:
> On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote:
> > > HJ's DT_RELR patch series has been upgraded to v7
> > > (https://patchwork.sourceware.org/project/glibc/list/?series=8295)
> > >
> > >   git-pw series apply 8295
> > >   # `Add --disable-default-dt-relr` does not apply cleanly
> > >
> > > If no regressions with default DT_RELR, that will be cool!
> >
> > I did find one error when testing a build of glibc using Ubuntu gcc-8.
> > elf/filter fails with "error while loading shared libraries:
> > .../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency".
> >
> > A little analysis shows the problem occurs when filtmod1.so is linked
> > with --as-needed and libc.so is not needed.  filtmod1.so ends up with
> > no .gnu.version or .gnu.version_r sections, and of course no
> > GLIBC_ABI_DT_RELR version.
> >
> > The error check is not one that belongs in ld.so.  If you have the
> > error checking code, then you have DT_RELR support in ld.so and there
> > is no reason at all to refuse to run the program!  The check should be
> > in the linker, if anywhere.
> >
> 
> The GLIBC_ABI_DT_RELR dependency is added to avoid the random
> crush at run-time with older glibc binaries.   Since it is possible to create
> a DSO with DT_RELR, but without the libc.so dependency.   Should ld.so
> skip the GLIBC_ABI_DT_RELR check if the DSO doesn't depend on
> libc.so?

I understand why you want a dependency, but I do not see a hard
requirement for l_abi_version or any code using it.  If you try to run
a new binary with DT_RELR using an old glibc or even current glibc
without relr support, you'll get "version `GLIBC_ABI_DT_RELR' not
found".  That is sufficient, presuming there is a GLIBC_ABI_DT_RELR
version in the binary.  If there *isn't* a GLIBC_ABI_DT_RELR version
then running that binary on an older glibc probably will crash.
Putting a check in a newer ld.so doesn't help much with that, except
show up this case where the dependency isn't there.  I guess the check
is justifiable under some DL_DEBUG flag.

Lack of a dependency is either a linker bug or a relr design bug.
Nitpick: isn't the actual dependency on ld.so rather than libc.so?
  

On Wed, Apr 13, 2022 at 10:19 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Apr 13, 2022 at 06:54:17PM -0700, H.J. Lu wrote:
> > On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> wrote:
> > >
> > > On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote:
> > > > HJ's DT_RELR patch series has been upgraded to v7
> > > > (https://patchwork.sourceware.org/project/glibc/list/?series=8295)
> > > >
> > > >   git-pw series apply 8295
> > > >   # `Add --disable-default-dt-relr` does not apply cleanly
> > > >
> > > > If no regressions with default DT_RELR, that will be cool!
> > >
> > > I did find one error when testing a build of glibc using Ubuntu gcc-8.
> > > elf/filter fails with "error while loading shared libraries:
> > > .../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency".
> > >
> > > A little analysis shows the problem occurs when filtmod1.so is linked
> > > with --as-needed and libc.so is not needed.  filtmod1.so ends up with
> > > no .gnu.version or .gnu.version_r sections, and of course no
> > > GLIBC_ABI_DT_RELR version.
> > >
> > > The error check is not one that belongs in ld.so.  If you have the
> > > error checking code, then you have DT_RELR support in ld.so and there
> > > is no reason at all to refuse to run the program!  The check should be
> > > in the linker, if anywhere.
> > >
> >
> > The GLIBC_ABI_DT_RELR dependency is added to avoid the random
> > crush at run-time with older glibc binaries.   Since it is possible to create
> > a DSO with DT_RELR, but without the libc.so dependency.   Should ld.so
> > skip the GLIBC_ABI_DT_RELR check if the DSO doesn't depend on
> > libc.so?
>
> I understand why you want a dependency, but I do not see a hard
> requirement for l_abi_version or any code using it.  If you try to run
> a new binary with DT_RELR using an old glibc or even current glibc
> without relr support, you'll get "version `GLIBC_ABI_DT_RELR' not
> found".  That is sufficient, presuming there is a GLIBC_ABI_DT_RELR
> version in the binary.  If there *isn't* a GLIBC_ABI_DT_RELR version
> then running that binary on an older glibc probably will crash.
> Putting a check in a newer ld.so doesn't help much with that, except
> show up this case where the dependency isn't there.  I guess the check
> is justifiable under some DL_DEBUG flag.
>
> Lack of a dependency is either a linker bug or a relr design bug.
> Nitpick: isn't the actual dependency on ld.so rather than libc.so?
>

The goal is to require a glibc with GLIBC_ABI_DT_RELR when
DT_RELR is used.  Since a shared library usually isn't linked
with ld.so, libc.so is checked.  I am working on v9 to support:

1. A DT_RELR shared library without DT_NEEDED.
2. A DT_RELR shared library without DT_VERNEED.
3. A DT_RELR shared library without libc.so on DT_NEEDED.