[PATCH] RISC-V: Enable static-pie.

[PATCH] RISC-V: Enable static-pie.

[yanzhang.wang]

From: Yanzhang Wang <yanzhang.wang@intel.com>

This patch referents the commit 374cef3 to add static-pie support. And
because the dummy link map is used when relocating ourselves, so need
not to set __global_pointer$ at this time.
---
 sysdeps/riscv/configure    | 2 ++
 sysdeps/riscv/configure.ac | 3 +++
 sysdeps/riscv/dl-machine.h | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
index 2372225a26..340163779f 100644
--- a/sysdeps/riscv/configure
+++ b/sysdeps/riscv/configure
@@ -29,3 +29,5 @@ fi
 $as_echo "$libc_cv_riscv_r_align" >&6; }
 config_vars="$config_vars
 riscv-r-align = $libc_cv_riscv_r_align"
+
+$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
index dbcc216689..36da2b5396 100644
--- a/sysdeps/riscv/configure.ac
+++ b/sysdeps/riscv/configure.ac
@@ -16,3 +16,6 @@ EOF
   fi
   rm -rf conftest.*])
 LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
+
+dnl Static PIE is supported.
+AC_DEFINE(SUPPORT_STATIC_PIE)
diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
index c0c9bd93ad..ad875c0828 100644
--- a/sysdeps/riscv/dl-machine.h
+++ b/sysdeps/riscv/dl-machine.h
@@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
       gotplt[1] = (ElfW(Addr)) l;
     }
 
-  if (l->l_type == lt_executable)
+  if (l->l_type == lt_executable && l->l_scope != NULL)
     {
       /* The __global_pointer$ may not be defined by the linker if the
 	 $gp register does not be used to access the global variable
-- 
2.41.0

Re: [PATCH] RISC-V: Enable static-pie.

[Palmer Dabbelt]

On Thu, 10 Aug 2023 16:33:48 PDT (-0700), libc-alpha@sourceware.org wrote:
> From: Yanzhang Wang <yanzhang.wang@intel.com>
>
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.

Do you have test results?  IIRC the only reason we didn't enable this 
when submitting the original port was because we didn't have time to 
test it.  If it's passing a reasonable amount of the tests it's fine 
with me, but we need to at least look because there could be lurking 
issues.

> ---
>  sysdeps/riscv/configure    | 2 ++
>  sysdeps/riscv/configure.ac | 3 +++
>  sysdeps/riscv/dl-machine.h | 2 +-
>  3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
> index 2372225a26..340163779f 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -29,3 +29,5 @@ fi
>  $as_echo "$libc_cv_riscv_r_align" >&6; }
>  config_vars="$config_vars
>  riscv-r-align = $libc_cv_riscv_r_align"
> +
> +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> index dbcc216689..36da2b5396 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,6 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Static PIE is supported.
> +AC_DEFINE(SUPPORT_STATIC_PIE)
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index c0c9bd93ad..ad875c0828 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>  	 $gp register does not be used to access the global variable

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Hi Palmer,

I have tested the commit(542b110585) with this patch. The results like below,

Summary of test results:
    189 FAIL
   4328 PASS
    101 UNSUPPORTED
     16 XFAIL
      2 XPASS

And the commit(542b110585)'s results like below,

Summary of test results:
    189 FAIL
   4326 PASS
    101 UNSUPPORTED
     16 XFAIL
      2 XPASS

The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.

I use the command make check-glibc-linux in riscv-gnu-toolchain. Not sure is
that acceptable.

Thanks,
Yanzhang

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Friday, August 11, 2023 9:58 AM
> To: libc-alpha@sourceware.org; Wang, Yanzhang <yanzhang.wang@intel.com>
> Cc: libc-alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> On Thu, 10 Aug 2023 16:33:48 PDT (-0700), libc-alpha@sourceware.org wrote:
> > From: Yanzhang Wang <yanzhang.wang@intel.com>
> >
> > This patch referents the commit 374cef3 to add static-pie support. And
> > because the dummy link map is used when relocating ourselves, so need
> > not to set __global_pointer$ at this time.
> 
> Do you have test results?  IIRC the only reason we didn't enable this when
> submitting the original port was because we didn't have time to test it.
> If it's passing a reasonable amount of the tests it's fine with me, but we
> need to at least look because there could be lurking issues.
> 
> > ---
> >  sysdeps/riscv/configure    | 2 ++
> >  sysdeps/riscv/configure.ac | 3 +++
> >  sysdeps/riscv/dl-machine.h | 2 +-
> >  3 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure index
> > 2372225a26..340163779f 100644
> > --- a/sysdeps/riscv/configure
> > +++ b/sysdeps/riscv/configure
> > @@ -29,3 +29,5 @@ fi
> >  $as_echo "$libc_cv_riscv_r_align" >&6; }  config_vars="$config_vars
> > riscv-r-align = $libc_cv_riscv_r_align"
> > +
> > +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> > diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> > index dbcc216689..36da2b5396 100644
> > --- a/sysdeps/riscv/configure.ac
> > +++ b/sysdeps/riscv/configure.ac
> > @@ -16,3 +16,6 @@ EOF
> >    fi
> >    rm -rf conftest.*])
> >  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> > +
> > +dnl Static PIE is supported.
> > +AC_DEFINE(SUPPORT_STATIC_PIE)
> > diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> > index c0c9bd93ad..ad875c0828 100644
> > --- a/sysdeps/riscv/dl-machine.h
> > +++ b/sysdeps/riscv/dl-machine.h
> > @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct
> r_scope_elem *scope[],
> >        gotplt[1] = (ElfW(Addr)) l;
> >      }
> >
> > -  if (l->l_type == lt_executable)
> > +  if (l->l_type == lt_executable && l->l_scope != NULL)
> >      {
> >        /* The __global_pointer$ may not be defined by the linker if the
> >  	 $gp register does not be used to access the global variable

Re: [PATCH] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> Hi Palmer,
> 
> I have tested the commit(542b110585) with this patch. The results like below,
> 
> Summary of test results:
>     189 FAIL
>    4328 PASS
>     101 UNSUPPORTED
>      16 XFAIL
>       2 XPASS
> 
> And the commit(542b110585)'s results like below,
> 
> Summary of test results:
>     189 FAIL
>    4326 PASS
>     101 UNSUPPORTED
>      16 XFAIL
>       2 XPASS
> 
> The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
> 
> I use the command make check-glibc-linux in riscv-gnu-toolchain. Not sure is
> that acceptable.

The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for all
the ABI variants.  The 189 failures you are reporting means that your 
environment is either missing some setup (for instance, copying the
libgcc_s.so and libstd++.so on the build folder so C++ and tests that
require pthread_cancel or backtrace works correctly) or it is not
properly configured.  

Please sort this out first, since with that amount of failures is not
straightforward to check whether static-pie is really working as
intended.

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

I took some time to test the master with binfmt_misc and qemu system mode.
Both of them can't match the requirements (<= 6 failures).

- most of cases with binfmt_misc fail with abort.
- most of cases with qemu system fail with timed out.

And also tested with my risc-v board and still fails 70+ cases and most of
them are math accuracy issue.

So Adhemerval, do you know how to setup the environment to reproduce
the <= 6 failures ? Maybe I lost some important steps. Thanks very much :).

Thanks,
Yanzhang

> -----Original Message-----
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> Sent: Tuesday, August 15, 2023 7:46 PM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> <palmer@dabbelt.com>; libc-alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> 
> 
> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> > Hi Palmer,
> >
> > I have tested the commit(542b110585) with this patch. The results like
> > below,
> >
> > Summary of test results:
> >     189 FAIL
> >    4328 PASS
> >     101 UNSUPPORTED
> >      16 XFAIL
> >       2 XPASS
> >
> > And the commit(542b110585)'s results like below,
> >
> > Summary of test results:
> >     189 FAIL
> >    4326 PASS
> >     101 UNSUPPORTED
> >      16 XFAIL
> >       2 XPASS
> >
> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
> >
> > I use the command make check-glibc-linux in riscv-gnu-toolchain. Not
> > sure is that acceptable.
> 
> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for all
> the ABI variants.  The 189 failures you are reporting means that your
> environment is either missing some setup (for instance, copying the
> libgcc_s.so and libstd++.so on the build folder so C++ and tests that
> require pthread_cancel or backtrace works correctly) or it is not
> properly configured.
> 
> Please sort this out first, since with that amount of failures is not
> straightforward to check whether static-pie is really working as intended.

RE: [PATCH] RISC-V: Enable static-pie.

[Palmer Dabbelt]

On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
> I took some time to test the master with binfmt_misc and qemu system mode.
> Both of them can't match the requirements (<= 6 failures).
> 
> - most of cases with binfmt_misc fail with abort.

QEMU user mode isn't a valid test suite target for glibc, there's lots 
of failures due to the emulation.  I know it's confusing that 
riscv-gnu-toolchain uses it, that come up when support was added.

> - most of cases with qemu system fail with timed out.

You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.

> And also tested with my risc-v board and still fails 70+ cases and most of
> them are math accuracy issue.

Which board are you running on?

> So Adhemerval, do you know how to setup the environment to reproduce
> the <= 6 failures ? Maybe I lost some important steps. Thanks very much :).

+DJ and Darius, who usually report test results.  They've probably got 
the best idea of how to set things up, but I don't remember this 
requiring anything fancy.

> 
> Thanks,
> Yanzhang
> 
>> -----Original Message-----
>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>> Sent: Tuesday, August 15, 2023 7:46 PM
>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>> 
>> 
>> 
>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
>> > Hi Palmer,
>> >
>> > I have tested the commit(542b110585) with this patch. The results like
>> > below,
>> >
>> > Summary of test results:
>> >     189 FAIL
>> >    4328 PASS
>> >     101 UNSUPPORTED
>> >      16 XFAIL
>> >       2 XPASS
>> >
>> > And the commit(542b110585)'s results like below,
>> >
>> > Summary of test results:
>> >     189 FAIL
>> >    4326 PASS
>> >     101 UNSUPPORTED
>> >      16 XFAIL
>> >       2 XPASS
>> >
>> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
>> >
>> > I use the command make check-glibc-linux in riscv-gnu-toolchain. Not
>> > sure is that acceptable.
>> 
>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for all
>> the ABI variants.  The 189 failures you are reporting means that your
>> environment is either missing some setup (for instance, copying the
>> libgcc_s.so and libstd++.so on the build folder so C++ and tests that
>> require pthread_cancel or backtrace works correctly) or it is not
>> properly configured.
>> 
>> Please sort this out first, since with that amount of failures is not
>> straightforward to check whether static-pie is really working as intended.
> 

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Thanks Palmer.

> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
>

I'll try to set a high value. It's really too slow.

> Which board are you running on?

I use the board licheepi 4a with Debian 12 to do the testing.

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Saturday, September 9, 2023 11:31 AM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>; DJ Delorie <dj@redhat.com>;
> Darius Rad <darius@bluespec.com>
> Cc: adhemerval.zanella@linaro.org; libc-alpha@sourceware.org
> Subject: RE: [PATCH] RISC-V: Enable static-pie.
> 
> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
> > I took some time to test the master with binfmt_misc and qemu system
> mode.
> > Both of them can't match the requirements (<= 6 failures).
> >
> > - most of cases with binfmt_misc fail with abort.
> 
> QEMU user mode isn't a valid test suite target for glibc, there's lots of
> failures due to the emulation.  I know it's confusing that riscv-gnu-
> toolchain uses it, that come up when support was added.
> 
> > - most of cases with qemu system fail with timed out.
> 
> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> 
> > And also tested with my risc-v board and still fails 70+ cases and
> > most of them are math accuracy issue.
> 
> Which board are you running on?
> 
> > So Adhemerval, do you know how to setup the environment to reproduce
> > the <= 6 failures ? Maybe I lost some important steps. Thanks very
> much :).
> 
> +DJ and Darius, who usually report test results.  They've probably got
> the best idea of how to set things up, but I don't remember this
> requiring anything fancy.
> 
> >
> > Thanks,
> > Yanzhang
> >
> >> -----Original Message-----
> >> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> >> Sent: Tuesday, August 15, 2023 7:46 PM
> >> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> >> <palmer@dabbelt.com>; libc-alpha@sourceware.org
> >> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> >>
> >>
> >>
> >> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> >> > Hi Palmer,
> >> >
> >> > I have tested the commit(542b110585) with this patch. The results
> >> > like below,
> >> >
> >> > Summary of test results:
> >> >     189 FAIL
> >> >    4328 PASS
> >> >     101 UNSUPPORTED
> >> >      16 XFAIL
> >> >       2 XPASS
> >> >
> >> > And the commit(542b110585)'s results like below,
> >> >
> >> > Summary of test results:
> >> >     189 FAIL
> >> >    4326 PASS
> >> >     101 UNSUPPORTED
> >> >      16 XFAIL
> >> >       2 XPASS
> >> >
> >> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
> >> >
> >> > I use the command make check-glibc-linux in riscv-gnu-toolchain.
> >> > Not sure is that acceptable.
> >>
> >> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for
> >> all the ABI variants.  The 189 failures you are reporting means that
> >> your environment is either missing some setup (for instance, copying
> >> the libgcc_s.so and libstd++.so on the build folder so C++ and tests
> >> that require pthread_cancel or backtrace works correctly) or it is
> >> not properly configured.
> >>
> >> Please sort this out first, since with that amount of failures is not
> >> straightforward to check whether static-pie is really working as
> intended.
> >

RE: [PATCH] RISC-V: Enable static-pie.

[Palmer Dabbelt]

On Fri, 08 Sep 2023 23:54:49 PDT (-0700), yanzhang.wang@intel.com wrote:
> Thanks Palmer.
> 
>> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
>>
> 
> I'll try to set a high value. It's really too slow.
> 
>> Which board are you running on?
> 
> I use the board licheepi 4a with Debian 12 to do the testing.

Those T-Head cores have a bit of a reputation for ignoring the ISA, so 
it wouldn't be super surprising if something odd is going on with 
floating point.  If the tests are clean on QEMU and fail on the C910 
then we should get to the bottom of it, though.

Last time I had to chase down an FPU bug I used TestFloat 
<http://www.jhauser.us/arithmetic/TestFloat.html>.  I'm not sure if 
there's something better?

+Edwin, as I think he's got Lichee Pi 4a up to benchmark misaligned 
accesses for that GCC patch.

> 
>> -----Original Message-----
>> From: Palmer Dabbelt <palmer@dabbelt.com>
>> Sent: Saturday, September 9, 2023 11:31 AM
>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; DJ Delorie <dj@redhat.com>;
>> Darius Rad <darius@bluespec.com>
>> Cc: adhemerval.zanella@linaro.org; libc-alpha@sourceware.org
>> Subject: RE: [PATCH] RISC-V: Enable static-pie.
>> 
>> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
>> > I took some time to test the master with binfmt_misc and qemu system
>> mode.
>> > Both of them can't match the requirements (<= 6 failures).
>> >
>> > - most of cases with binfmt_misc fail with abort.
>> 
>> QEMU user mode isn't a valid test suite target for glibc, there's lots of
>> failures due to the emulation.  I know it's confusing that riscv-gnu-
>> toolchain uses it, that come up when support was added.
>> 
>> > - most of cases with qemu system fail with timed out.
>> 
>> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
>> 
>> > And also tested with my risc-v board and still fails 70+ cases and
>> > most of them are math accuracy issue.
>> 
>> Which board are you running on?
>> 
>> > So Adhemerval, do you know how to setup the environment to reproduce
>> > the <= 6 failures ? Maybe I lost some important steps. Thanks very
>> much :).
>> 
>> +DJ and Darius, who usually report test results.  They've probably got
>> the best idea of how to set things up, but I don't remember this
>> requiring anything fancy.
>> 
>> >
>> > Thanks,
>> > Yanzhang
>> >
>> >> -----Original Message-----
>> >> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>> >> Sent: Tuesday, August 15, 2023 7:46 PM
>> >> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>> >> <palmer@dabbelt.com>; libc-alpha@sourceware.org
>> >> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>> >>
>> >>
>> >>
>> >> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
>> >> > Hi Palmer,
>> >> >
>> >> > I have tested the commit(542b110585) with this patch. The results
>> >> > like below,
>> >> >
>> >> > Summary of test results:
>> >> >     189 FAIL
>> >> >    4328 PASS
>> >> >     101 UNSUPPORTED
>> >> >      16 XFAIL
>> >> >       2 XPASS
>> >> >
>> >> > And the commit(542b110585)'s results like below,
>> >> >
>> >> > Summary of test results:
>> >> >     189 FAIL
>> >> >    4326 PASS
>> >> >     101 UNSUPPORTED
>> >> >      16 XFAIL
>> >> >       2 XPASS
>> >> >
>> >> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
>> >> >
>> >> > I use the command make check-glibc-linux in riscv-gnu-toolchain.
>> >> > Not sure is that acceptable.
>> >>
>> >> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for
>> >> all the ABI variants.  The 189 failures you are reporting means that
>> >> your environment is either missing some setup (for instance, copying
>> >> the libgcc_s.so and libstd++.so on the build folder so C++ and tests
>> >> that require pthread_cancel or backtrace works correctly) or it is
>> >> not properly configured.
>> >>
>> >> Please sort this out first, since with that amount of failures is not
>> >> straightforward to check whether static-pie is really working as
>> intended.
>> >

Re: [PATCH] RISC-V: Enable static-pie.

[Darius Rad]

On Fri, Sep 08, 2023 at 08:30:44PM -0700, Palmer Dabbelt wrote:
> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
> > I took some time to test the master with binfmt_misc and qemu system mode.
> > Both of them can't match the requirements (<= 6 failures).
> > 
> > - most of cases with binfmt_misc fail with abort.
> 
> QEMU user mode isn't a valid test suite target for glibc, there's lots of
> failures due to the emulation.  I know it's confusing that
> riscv-gnu-toolchain uses it, that come up when support was added.
> 
> > - most of cases with qemu system fail with timed out.
> 
> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> 
> > And also tested with my risc-v board and still fails 70+ cases and most of
> > them are math accuracy issue.
> 
> Which board are you running on?
> 
> > So Adhemerval, do you know how to setup the environment to reproduce
> > the <= 6 failures ? Maybe I lost some important steps. Thanks very much :).
> 
> +DJ and Darius, who usually report test results.  They've probably got the
> best idea of how to set things up, but I don't remember this requiring
> anything fancy.
> 

Indeed, I don't really do anything unusual, but I do set TIMEOUTFACTOR to
10.  I regularly run on qemu-system (not user) and the Microchip Icicle Kit
board.  I also use scripts/cross-test-ssh.sh for test-wrapper, even when
testing locally (host is localhost), as that simplifies testing the various
ABIs.

// darius

Re: [PATCH] RISC-V: Enable static-pie.

[DJ Delorie]

Darius Rad <darius@bluespec.com> writes:
> Indeed, I don't really do anything unusual, but I do set TIMEOUTFACTOR to
> 10.

Likewise, I set TIMEOUTFACTOR to 20 and do nothing else special.  My
regular board is an unmatched with an M.2 drive to make it as speedy as
possible, but our (RH) policy is to set TIMEOUTFACTOR for all builds,
even x86.

Re: [PATCH] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 09/09/23 00:30, Palmer Dabbelt wrote:
> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
>> I took some time to test the master with binfmt_misc and qemu system mode.
>> Both of them can't match the requirements (<= 6 failures).
>>
>> - most of cases with binfmt_misc fail with abort.
> 
> QEMU user mode isn't a valid test suite target for glibc, there's lots of failures due to the emulation.  I know it's confusing that riscv-gnu-toolchain uses it, that come up when support was added.
> 
>> - most of cases with qemu system fail with timed out.
> 
> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> 
>> And also tested with my risc-v board and still fails 70+ cases and most of
>> them are math accuracy issue.
> 
> Which board are you running on?
> 
>> So Adhemerval, do you know how to setup the environment to reproduce
>> the <= 6 failures ? Maybe I lost some important steps. Thanks very much :).
> 
> +DJ and Darius, who usually report test results.  They've probably got the best idea of how to set things up, but I don't remember this requiring anything fancy.

For the specific support of static-pie, I expect that qemu-system or even
qemu-user would be a feasible testing platform.  You might need some 
adjustment if the platform implements some math code in assembly, but 
if you filter out the expected failures it should be doable to check
the feature is working as intended.

However it is hard to filter out if you just specify the number of failure 
before/after without breaking down which tests has failed and why (Was is 
due timeout due emulation? Was it due missing libstdc++.so/libgcc_s.so 
support? Was is math failure due wrong emulation?). 

> 
>>
>> Thanks,
>> Yanzhang
>>
>>> -----Original Message-----
>>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>>> Sent: Tuesday, August 15, 2023 7:46 PM
>>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
>>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>>>
>>>
>>>
>>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
>>> > Hi Palmer,
>>> >
>>> > I have tested the commit(542b110585) with this patch. The results like
>>> > below,
>>> >
>>> > Summary of test results:
>>> >     189 FAIL
>>> >    4328 PASS
>>> >     101 UNSUPPORTED
>>> >      16 XFAIL
>>> >       2 XPASS
>>> >
>>> > And the commit(542b110585)'s results like below,
>>> >
>>> > Summary of test results:
>>> >     189 FAIL
>>> >    4326 PASS
>>> >     101 UNSUPPORTED
>>> >      16 XFAIL
>>> >       2 XPASS
>>> >
>>> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
>>> >
>>> > I use the command make check-glibc-linux in riscv-gnu-toolchain. Not
>>> > sure is that acceptable.
>>>
>>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for all
>>> the ABI variants.  The 189 failures you are reporting means that your
>>> environment is either missing some setup (for instance, copying the
>>> libgcc_s.so and libstd++.so on the build folder so C++ and tests that
>>> require pthread_cancel or backtrace works correctly) or it is not
>>> properly configured.
>>>
>>> Please sort this out first, since with that amount of failures is not
>>> straightforward to check whether static-pie is really working as intended.
>>

Re: [PATCH] RISC-V: Enable static-pie.

[Palmer Dabbelt]

On Mon, 11 Sep 2023 09:17:22 PDT (-0700), adhemerval.zanella@linaro.org wrote:
>
>
> On 09/09/23 00:30, Palmer Dabbelt wrote:
>> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
>>> I took some time to test the master with binfmt_misc and qemu system mode.
>>> Both of them can't match the requirements (<= 6 failures).
>>>
>>> - most of cases with binfmt_misc fail with abort.
>>
>> QEMU user mode isn't a valid test suite target for glibc, there's lots of failures due to the emulation.  I know it's confusing that riscv-gnu-toolchain uses it, that come up when support was added.
>>
>>> - most of cases with qemu system fail with timed out.
>>
>> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
>>
>>> And also tested with my risc-v board and still fails 70+ cases and most of
>>> them are math accuracy issue.
>>
>> Which board are you running on?
>>
>>> So Adhemerval, do you know how to setup the environment to reproduce
>>> the <= 6 failures ? Maybe I lost some important steps. Thanks very much :).
>>
>> +DJ and Darius, who usually report test results.  They've probably got the best idea of how to set things up, but I don't remember this requiring anything fancy.
>
> For the specific support of static-pie, I expect that qemu-system or even
> qemu-user would be a feasible testing platform.  You might need some
> adjustment if the platform implements some math code in assembly, but
> if you filter out the expected failures it should be doable to check
> the feature is working as intended.

It looks like the HW in question likely has some issues in the FPU, see 
<https://github.com/revyos/revyos/issues/17>.  We'll have to figure 
something out (maybe just disable FP until userspace has ack'd that it 
understands the errata?), but for now it's probably best to just test on 
QEMU.

> However it is hard to filter out if you just specify the number of failure
> before/after without breaking down which tests has failed and why (Was is
> due timeout due emulation? Was it due missing libstdc++.so/libgcc_s.so
> support? Was is math failure due wrong emulation?).
>
>>
>>>
>>> Thanks,
>>> Yanzhang
>>>
>>>> -----Original Message-----
>>>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>>>> Sent: Tuesday, August 15, 2023 7:46 PM
>>>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>>>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
>>>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>>>>
>>>>
>>>>
>>>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
>>>> > Hi Palmer,
>>>> >
>>>> > I have tested the commit(542b110585) with this patch. The results like
>>>> > below,
>>>> >
>>>> > Summary of test results:
>>>> >     189 FAIL
>>>> >    4328 PASS
>>>> >     101 UNSUPPORTED
>>>> >      16 XFAIL
>>>> >       2 XPASS
>>>> >
>>>> > And the commit(542b110585)'s results like below,
>>>> >
>>>> > Summary of test results:
>>>> >     189 FAIL
>>>> >    4326 PASS
>>>> >     101 UNSUPPORTED
>>>> >      16 XFAIL
>>>> >       2 XPASS
>>>> >
>>>> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
>>>> >
>>>> > I use the command make check-glibc-linux in riscv-gnu-toolchain. Not
>>>> > sure is that acceptable.
>>>>
>>>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL for all
>>>> the ABI variants.  The 189 failures you are reporting means that your
>>>> environment is either missing some setup (for instance, copying the
>>>> libgcc_s.so and libstd++.so on the build folder so C++ and tests that
>>>> require pthread_cancel or backtrace works correctly) or it is not
>>>> properly configured.
>>>>
>>>> Please sort this out first, since with that amount of failures is not
>>>> straightforward to check whether static-pie is really working as intended.
>>>

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
Your suggestions are so helpful to me.

Yes. I also found this issue on GitHub too and the math failures didn't
appear with QEMU system. So it's definitely a hardware bug.

And I found the root cause of almost of the other failures. It's
because I use sshfs not nfs. :( ..

Even though I set a larger TIMEOUTFACTOR as you said, there're still
some timeout failures like below. And seems the timeout is not stable.
Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.

  master with qemu-system       master on lp4a                static-pie patch on lp4a     
 ----------------------------- ----------------------------- ----------------------------- 
  resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit  
  nptl/tst-stack4               nptl/tst-stack4               iconvdata/tst-loading        
  libio/tst-fopenloc            libio/tst-fopenloc            localedata/tst-leaks         
  iconvdata/tst-loading         iconvdata/tst-loading         malloc/tst-dynarray-fail     
  localedata/tst-leaks          localedata/tst-leaks          posix/tst-fnmatch            
  malloc/tst-dynarray-fail      malloc/tst-dynarray-fail                                   
  posix/tst-glob-tilde          posix/tst-glob-tilde                                       
  posix/tst-fnmatch             posix/tst-fnmatch                                          

For the FAIL tests, it's like below. The math failures are filtered out
on lp4a and not appear on qemu-system.

  master with qemu-system                         master on lp4a                                  static-pie patch on lp4a                       
 ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- 
  resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit             
  nptl/tst-cancel21-static                        libio/tst-fopenloc-mem                          elf/tst-tls-allocation-failure-static-patched  
  libio/tst-fopenloc-mem                          libio/tst-fopenloc-cmp                          elf/tst-rtld-list-diagnostics                  
  libio/tst-fopenloc-cmp                          elf/tst-tls-allocation-failure-static-patched   elf/tst-sprof-basic                            
  elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-diagnostics                   iconvdata/mtrace-tst-loading                   
  elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic                             localedata/mtrace-tst-leaks                    
  elf/tst-sprof-basic                             iconvdata/mtrace-tst-loading                    malloc/tst-dynarray-fail-mem                   
  iconvdata/mtrace-tst-loading                    localedata/mtrace-tst-leaks                     posix/tst-fnmatch-mem                          
  localedata/mtrace-tst-leaks                     malloc/tst-dynarray-fail-mem                                                                   
  malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-mem                                                                       
  posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem                                                                          
  posix/tst-fnmatch-mem                                                                                                                          
  posix/globtest                                                                                                                                 

Take master on lp4a as an example,

- elf/tst-rtld-list-diagnostics, due to missing abnf module
- elf/tst-sprof-basic, successfully print hello world but return status is 1, still unknown root cause
- elf/tst-tls-allocation-failure-static-patched, exec format error, still unknown root cause
- the others are memory not freed

The difference between qemu-system and lp4a for master is the two cases,

- nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't investigated.
- posix/globtest, because my qemu-system has a different user name.

The XFAILs and XPASSes are the same on all platforms and all branches.
So not list here.

I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master branch.

So is this the expected test result? Or is there still any case not correct FAIL or PASS?

Thanks,
Yanzhang

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Wednesday, September 20, 2023 9:37 PM
> To: adhemerval.zanella@linaro.org
> Cc: Wang, Yanzhang <yanzhang.wang@intel.com>; DJ Delorie <dj@redhat.com>;
> Darius Rad <darius@bluespec.com>; libc-alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> On Mon, 11 Sep 2023 09:17:22 PDT (-0700), adhemerval.zanella@linaro.org
> wrote:
> >
> >
> > On 09/09/23 00:30, Palmer Dabbelt wrote:
> >> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com wrote:
> >>> I took some time to test the master with binfmt_misc and qemu system
> mode.
> >>> Both of them can't match the requirements (<= 6 failures).
> >>>
> >>> - most of cases with binfmt_misc fail with abort.
> >>
> >> QEMU user mode isn't a valid test suite target for glibc, there's lots
> of failures due to the emulation.  I know it's confusing that riscv-gnu-
> toolchain uses it, that come up when support was added.
> >>
> >>> - most of cases with qemu system fail with timed out.
> >>
> >> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> >>
> >>> And also tested with my risc-v board and still fails 70+ cases and
> >>> most of them are math accuracy issue.
> >>
> >> Which board are you running on?
> >>
> >>> So Adhemerval, do you know how to setup the environment to reproduce
> >>> the <= 6 failures ? Maybe I lost some important steps. Thanks very
> much :).
> >>
> >> +DJ and Darius, who usually report test results.  They've probably got
> the best idea of how to set things up, but I don't remember this requiring
> anything fancy.
> >
> > For the specific support of static-pie, I expect that qemu-system or
> > even qemu-user would be a feasible testing platform.  You might need
> > some adjustment if the platform implements some math code in assembly,
> > but if you filter out the expected failures it should be doable to
> > check the feature is working as intended.
> 
> It looks like the HW in question likely has some issues in the FPU, see
> <https://github.com/revyos/revyos/issues/17>.  We'll have to figure
> something out (maybe just disable FP until userspace has ack'd that it
> understands the errata?), but for now it's probably best to just test on
> QEMU.
> 
> > However it is hard to filter out if you just specify the number of
> > failure before/after without breaking down which tests has failed and
> > why (Was is due timeout due emulation? Was it due missing
> > libstdc++.so/libgcc_s.so support? Was is math failure due wrong
> emulation?).
> >
> >>
> >>>
> >>> Thanks,
> >>> Yanzhang
> >>>
> >>>> -----Original Message-----
> >>>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> >>>> Sent: Tuesday, August 15, 2023 7:46 PM
> >>>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> >>>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
> >>>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> >>>>
> >>>>
> >>>>
> >>>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> >>>> > Hi Palmer,
> >>>> >
> >>>> > I have tested the commit(542b110585) with this patch. The results
> >>>> > like below,
> >>>> >
> >>>> > Summary of test results:
> >>>> >     189 FAIL
> >>>> >    4328 PASS
> >>>> >     101 UNSUPPORTED
> >>>> >      16 XFAIL
> >>>> >       2 XPASS
> >>>> >
> >>>> > And the commit(542b110585)'s results like below,
> >>>> >
> >>>> > Summary of test results:
> >>>> >     189 FAIL
> >>>> >    4326 PASS
> >>>> >     101 UNSUPPORTED
> >>>> >      16 XFAIL
> >>>> >       2 XPASS
> >>>> >
> >>>> > The binutils's commit is 2db20b97f1d and gcc's commit is bf36656a14a.
> >>>> >
> >>>> > I use the command make check-glibc-linux in riscv-gnu-toolchain.
> >>>> > Not sure is that acceptable.
> >>>>
> >>>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL
> >>>> for all the ABI variants.  The 189 failures you are reporting means
> >>>> that your environment is either missing some setup (for instance,
> >>>> copying the libgcc_s.so and libstd++.so on the build folder so C++
> >>>> and tests that require pthread_cancel or backtrace works correctly)
> >>>> or it is not properly configured.
> >>>>
> >>>> Please sort this out first, since with that amount of failures is
> >>>> not straightforward to check whether static-pie is really working as
> intended.
> >>>

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Hi,

Is there any further comments about this patch?

I have pushed another v2 version someday ago, and there's no conflict now.
https://patchwork.sourceware.org/project/glibc/patch/20230815014434.1902446-1-yanzhang.wang@intel.com/

Thanks,
Yanzhang

> -----Original Message-----
> From: Wang, Yanzhang
> Sent: Thursday, September 21, 2023 9:48 PM
> To: Palmer Dabbelt <palmer@dabbelt.com>; adhemerval.zanella@linaro.org
> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
> alpha@sourceware.org
> Subject: RE: [PATCH] RISC-V: Enable static-pie.
> 
> Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
> Your suggestions are so helpful to me.
> 
> Yes. I also found this issue on GitHub too and the math failures didn't
> appear with QEMU system. So it's definitely a hardware bug.
> 
> And I found the root cause of almost of the other failures. It's because I
> use sshfs not nfs. :( ..
> 
> Even though I set a larger TIMEOUTFACTOR as you said, there're still some
> timeout failures like below. And seems the timeout is not stable.
> Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.
> 
>   master with qemu-system       master on lp4a                static-pie
> patch on lp4a
>  ----------------------------- ----------------------------- --------------
> ---------------
>   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit   resolv/tst-
> resolv-res_ninit
>   nptl/tst-stack4               nptl/tst-stack4
> iconvdata/tst-loading
>   libio/tst-fopenloc            libio/tst-fopenloc
> localedata/tst-leaks
>   iconvdata/tst-loading         iconvdata/tst-loading         malloc/tst-
> dynarray-fail
>   localedata/tst-leaks          localedata/tst-leaks          posix/tst-
> fnmatch
>   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail
>   posix/tst-glob-tilde          posix/tst-glob-tilde
>   posix/tst-fnmatch             posix/tst-fnmatch
> 
> For the FAIL tests, it's like below. The math failures are filtered out on
> lp4a and not appear on qemu-system.
> 
>   master with qemu-system                         master on lp4a
> static-pie patch on lp4a
>  ----------------------------------------------- --------------------------
> --------------------- -----------------------------------------------
>   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-resolv-
> res_ninit              resolv/mtrace-tst-resolv-res_ninit
>   nptl/tst-cancel21-static                        libio/tst-fopenloc-mem
> elf/tst-tls-allocation-failure-static-patched
>   libio/tst-fopenloc-mem                          libio/tst-fopenloc-cmp
> elf/tst-rtld-list-diagnostics
>   libio/tst-fopenloc-cmp                          elf/tst-tls-allocation-
> failure-static-patched   elf/tst-sprof-basic
>   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-
> diagnostics                   iconvdata/mtrace-tst-loading
>   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic
> localedata/mtrace-tst-leaks
>   elf/tst-sprof-basic                             iconvdata/mtrace-tst-
> loading                    malloc/tst-dynarray-fail-mem
>   iconvdata/mtrace-tst-loading                    localedata/mtrace-tst-
> leaks                     posix/tst-fnmatch-mem
>   localedata/mtrace-tst-leaks                     malloc/tst-dynarray-fail-
> mem
>   malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-mem
>   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem
>   posix/tst-fnmatch-mem
>   posix/globtest
> 
> Take master on lp4a as an example,
> 
> - elf/tst-rtld-list-diagnostics, due to missing abnf module
> - elf/tst-sprof-basic, successfully print hello world but return status is
> 1, still unknown root cause
> - elf/tst-tls-allocation-failure-static-patched, exec format error, still
> unknown root cause
> - the others are memory not freed
> 
> The difference between qemu-system and lp4a for master is the two cases,
> 
> - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't
> investigated.
> - posix/globtest, because my qemu-system has a different user name.
> 
> The XFAILs and XPASSes are the same on all platforms and all branches.
> So not list here.
> 
> I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master branch.
> 
> So is this the expected test result? Or is there still any case not correct
> FAIL or PASS?
> 
> Thanks,
> Yanzhang
> 
> > -----Original Message-----
> > From: Palmer Dabbelt <palmer@dabbelt.com>
> > Sent: Wednesday, September 20, 2023 9:37 PM
> > To: adhemerval.zanella@linaro.org
> > Cc: Wang, Yanzhang <yanzhang.wang@intel.com>; DJ Delorie
> > <dj@redhat.com>; Darius Rad <darius@bluespec.com>;
> > libc-alpha@sourceware.org
> > Subject: Re: [PATCH] RISC-V: Enable static-pie.
> >
> > On Mon, 11 Sep 2023 09:17:22 PDT (-0700),
> > adhemerval.zanella@linaro.org
> > wrote:
> > >
> > >
> > > On 09/09/23 00:30, Palmer Dabbelt wrote:
> > >> On Fri, 08 Sep 2023 20:17:16 PDT (-0700), yanzhang.wang@intel.com
> wrote:
> > >>> I took some time to test the master with binfmt_misc and qemu
> > >>> system
> > mode.
> > >>> Both of them can't match the requirements (<= 6 failures).
> > >>>
> > >>> - most of cases with binfmt_misc fail with abort.
> > >>
> > >> QEMU user mode isn't a valid test suite target for glibc, there's
> > >> lots
> > of failures due to the emulation.  I know it's confusing that
> > riscv-gnu- toolchain uses it, that come up when support was added.
> > >>
> > >>> - most of cases with qemu system fail with timed out.
> > >>
> > >> You can set TIMEOUTFACTOR, qemu-system is a lot slower than hardware.
> > >>
> > >>> And also tested with my risc-v board and still fails 70+ cases and
> > >>> most of them are math accuracy issue.
> > >>
> > >> Which board are you running on?
> > >>
> > >>> So Adhemerval, do you know how to setup the environment to
> > >>> reproduce the <= 6 failures ? Maybe I lost some important steps.
> > >>> Thanks very
> > much :).
> > >>
> > >> +DJ and Darius, who usually report test results.  They've probably
> > >> +got
> > the best idea of how to set things up, but I don't remember this
> > requiring anything fancy.
> > >
> > > For the specific support of static-pie, I expect that qemu-system or
> > > even qemu-user would be a feasible testing platform.  You might need
> > > some adjustment if the platform implements some math code in
> > > assembly, but if you filter out the expected failures it should be
> > > doable to check the feature is working as intended.
> >
> > It looks like the HW in question likely has some issues in the FPU,
> > see <https://github.com/revyos/revyos/issues/17>.  We'll have to
> > figure something out (maybe just disable FP until userspace has ack'd
> > that it understands the errata?), but for now it's probably best to
> > just test on QEMU.
> >
> > > However it is hard to filter out if you just specify the number of
> > > failure before/after without breaking down which tests has failed
> > > and why (Was is due timeout due emulation? Was it due missing
> > > libstdc++.so/libgcc_s.so support? Was is math failure due wrong
> > emulation?).
> > >
> > >>
> > >>>
> > >>> Thanks,
> > >>> Yanzhang
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> > >>>> Sent: Tuesday, August 15, 2023 7:46 PM
> > >>>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> > >>>> <palmer@dabbelt.com>; libc-alpha@sourceware.org
> > >>>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 13/08/23 09:20, Wang, Yanzhang via Libc-alpha wrote:
> > >>>> > Hi Palmer,
> > >>>> >
> > >>>> > I have tested the commit(542b110585) with this patch. The
> > >>>> > results like below,
> > >>>> >
> > >>>> > Summary of test results:
> > >>>> >     189 FAIL
> > >>>> >    4328 PASS
> > >>>> >     101 UNSUPPORTED
> > >>>> >      16 XFAIL
> > >>>> >       2 XPASS
> > >>>> >
> > >>>> > And the commit(542b110585)'s results like below,
> > >>>> >
> > >>>> > Summary of test results:
> > >>>> >     189 FAIL
> > >>>> >    4326 PASS
> > >>>> >     101 UNSUPPORTED
> > >>>> >      16 XFAIL
> > >>>> >       2 XPASS
> > >>>> >
> > >>>> > The binutils's commit is 2db20b97f1d and gcc's commit is
> bf36656a14a.
> > >>>> >
> > >>>> > I use the command make check-glibc-linux in riscv-gnu-toolchain.
> > >>>> > Not sure is that acceptable.
> > >>>>
> > >>>> The riscv reports for 2.38 release [1] list at maximum of 6 FAIL
> > >>>> for all the ABI variants.  The 189 failures you are reporting
> > >>>> means that your environment is either missing some setup (for
> > >>>> instance, copying the libgcc_s.so and libstd++.so on the build
> > >>>> folder so C++ and tests that require pthread_cancel or backtrace
> > >>>> works correctly) or it is not properly configured.
> > >>>>
> > >>>> Please sort this out first, since with that amount of failures is
> > >>>> not straightforward to check whether static-pie is really working
> > >>>> as
> > intended.
> > >>>

Re: [PATCH] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 21/09/23 10:47, Wang, Yanzhang wrote:
> Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
> Your suggestions are so helpful to me.
> 
> Yes. I also found this issue on GitHub too and the math failures didn't
> appear with QEMU system. So it's definitely a hardware bug.
> 
> And I found the root cause of almost of the other failures. It's
> because I use sshfs not nfs. :( ..

I don't have access to RISCV hardware, but we can use the 2.38 release [1] as the
baseline [1].

> 
> Even though I set a larger TIMEOUTFACTOR as you said, there're still
> some timeout failures like below. And seems the timeout is not stable.
> Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.

The tst-stack4 was a long standing issue that should be fixed on master [2].

> 
>   master with qemu-system       master on lp4a                static-pie patch on lp4a     
>  ----------------------------- ----------------------------- ----------------------------- 
>   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit  
>   nptl/tst-stack4               nptl/tst-stack4               iconvdata/tst-loading        
>   libio/tst-fopenloc            libio/tst-fopenloc            localedata/tst-leaks         
>   iconvdata/tst-loading         iconvdata/tst-loading         malloc/tst-dynarray-fail     
>   localedata/tst-leaks          localedata/tst-leaks          posix/tst-fnmatch            
>   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail                                   
>   posix/tst-glob-tilde          posix/tst-glob-tilde                                       
>   posix/tst-fnmatch             posix/tst-fnmatch   


For static-pie I would focus on the *static* tests and check for any regressions.
On the above, all are dynamic and most likely the timeout you have found are due
a low TIMEOUTFACTOR value.

You can check by testing each one individually: 

$ TIMEOUTFACTOR=100 make test t=<test> # for instance, posix/tst-fnmatch
                                       
> 
> For the FAIL tests, it's like below. The math failures are filtered out
> on lp4a and not appear on qemu-system.
> 
>   master with qemu-system                         master on lp4a                                  static-pie patch on lp4a                       
>  ----------------------------------------------- ----------------------------------------------- ----------------------------------------------- 
>   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit             
>   nptl/tst-cancel21-static                        libio/tst-fopenloc-mem                          elf/tst-tls-allocation-failure-static-patched  
>   libio/tst-fopenloc-mem                          libio/tst-fopenloc-cmp                          elf/tst-rtld-list-diagnostics                  
>   libio/tst-fopenloc-cmp                          elf/tst-tls-allocation-failure-static-patched   elf/tst-sprof-basic                            
>   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-diagnostics                   iconvdata/mtrace-tst-loading                   
>   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic                             localedata/mtrace-tst-leaks                    
>   elf/tst-sprof-basic                             iconvdata/mtrace-tst-loading                    malloc/tst-dynarray-fail-mem                   
>   iconvdata/mtrace-tst-loading                    localedata/mtrace-tst-leaks                     posix/tst-fnmatch-mem                          
>   localedata/mtrace-tst-leaks                     malloc/tst-dynarray-fail-mem                                                                   
>   malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-mem                                                                       
>   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem                                                                          
>   posix/tst-fnmatch-mem                                                                                                                          
>   posix/globtest          

The elf/tst-sprof-basic seems to be a know issue based on 2.38 release wiki, and
most of them seems also for related to the low TIMEOUTFACTOR.
                                                                                                                       
> 
> Take master on lp4a as an example,
> 
> - elf/tst-rtld-list-diagnostics, due to missing abnf module
> - elf/tst-sprof-basic, successfully print hello world but return status is 1, still unknown root cause
> - elf/tst-tls-allocation-failure-static-patched, exec format error, still unknown root cause

This seems to be a real regression, and I think you should sort this out before
the patch is installed (I see no failure on qemu-user on master).  The exec format
error seems to come from kernel, due the execve failure; and might a corrupted
binary.

> - the others are memory not freed
> 
> The difference between qemu-system and lp4a for master is the two cases,
> 
> - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't investigated.

This might a unrelated issue [3], either in compiler optimization or due the
the long-standing BZ#12683 issue.

> - posix/globtest, because my qemu-system has a different user name.
> 
> The XFAILs and XPASSes are the same on all platforms and all branches.
> So not list here.
> 
> I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master branch.
> 
> So is this the expected test result? Or is there still any case not correct FAIL or PASS?

I think the output look pretty ok, the only issue being the
elf/tst-tls-allocation-failure-static failure.


[1] https://sourceware.org/glibc/wiki/Release/2.38#RISC-V_.28rv64imac.2Flp64.29
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=19329
[3] https://sourceware.org/pipermail/libc-alpha/2019-September/106641.html

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Hi Adhemerval,

Thanks for your comments and the two categories cases are all figured out.

For the timed out cases, I increased the TIMEOUTFACTOR to 300 and finally passed.
The 100 seems not working very well.

For the case elf/tst-tls-allocation-failure-static-patched, the root cause is it
does not run with test-wrapper. I use cross-test-ssh.sh to run tests on the board.
If no test-wrapper, it will run on my local. That's why exec format error.

I need to apply another patch below. Is it acceptable or I need to run the full
test directly on board?

diff --git a/elf/Makefile b/elf/Makefile
index 9176cbf1e3..1065b5c123 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -2979,7 +2979,7 @@ $(objpfx)tst-tls-allocation-failure-static-patched: \

 $(objpfx)tst-tls-allocation-failure-static-patched.out: \
   $(objpfx)tst-tls-allocation-failure-static-patched
-       $< > $@ 2>&1; echo "status: $$?" >> $@
+       $(test-wrapper) $< > $@ 2>&1; echo "status: $$?" >> $@
        grep -q '^Fatal glibc error: Cannot allocate TLS block$$' $@ \
          && grep -q '^status: 127$$' $@; \
          $(evaluate-test)
 

> -----Original Message-----
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> Sent: Tuesday, October 17, 2023 9:42 PM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> <palmer@dabbelt.com>
> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
> alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> 
> 
> On 21/09/23 10:47, Wang, Yanzhang wrote:
> > Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
> > Your suggestions are so helpful to me.
> >
> > Yes. I also found this issue on GitHub too and the math failures
> > didn't appear with QEMU system. So it's definitely a hardware bug.
> >
> > And I found the root cause of almost of the other failures. It's
> > because I use sshfs not nfs. :( ..
> 
> I don't have access to RISCV hardware, but we can use the 2.38 release [1]
> as the baseline [1].
> 
> >
> > Even though I set a larger TIMEOUTFACTOR as you said, there're still
> > some timeout failures like below. And seems the timeout is not stable.
> > Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.
> 
> The tst-stack4 was a long standing issue that should be fixed on master
> [2].
> 
> >
> >   master with qemu-system       master on lp4a                static-
> pie patch on lp4a
> >  ----------------------------- ----------------------------- ----------
> -------------------
> >   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit
> resolv/tst-resolv-res_ninit
> >   nptl/tst-stack4               nptl/tst-stack4
> iconvdata/tst-loading
> >   libio/tst-fopenloc            libio/tst-fopenloc
> localedata/tst-leaks
> >   iconvdata/tst-loading         iconvdata/tst-loading
> malloc/tst-dynarray-fail
> >   localedata/tst-leaks          localedata/tst-leaks
> posix/tst-fnmatch
> >   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail
> >   posix/tst-glob-tilde          posix/tst-glob-tilde
> >   posix/tst-fnmatch             posix/tst-fnmatch
> 
> 
> For static-pie I would focus on the *static* tests and check for any
> regressions.
> On the above, all are dynamic and most likely the timeout you have found
> are due a low TIMEOUTFACTOR value.
> 
> You can check by testing each one individually:
> 
> $ TIMEOUTFACTOR=100 make test t=<test> # for instance, posix/tst-fnmatch
> 
> >
> > For the FAIL tests, it's like below. The math failures are filtered
> > out on lp4a and not appear on qemu-system.
> >
> >   master with qemu-system                         master on lp4a
> static-pie patch on lp4a
> >  ----------------------------------------------- ----------------------
> ------------------------- -----------------------------------------------
> >   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-
> resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit
> >   nptl/tst-cancel21-static                        libio/tst-fopenloc-
> mem                          elf/tst-tls-allocation-failure-static-
> patched
> >   libio/tst-fopenloc-mem                          libio/tst-fopenloc-
> cmp                          elf/tst-rtld-list-diagnostics
> >   libio/tst-fopenloc-cmp                          elf/tst-tls-
> allocation-failure-static-patched   elf/tst-sprof-basic
> >   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-
> diagnostics                   iconvdata/mtrace-tst-loading
> >   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic
> localedata/mtrace-tst-leaks
> >   elf/tst-sprof-basic                             iconvdata/mtrace-tst-
> loading                    malloc/tst-dynarray-fail-mem
> >   iconvdata/mtrace-tst-loading                    localedata/mtrace-
> tst-leaks                     posix/tst-fnmatch-mem
> >   localedata/mtrace-tst-leaks                     malloc/tst-dynarray-
> fail-mem
> >   malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-
> mem
> >   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem
> >   posix/tst-fnmatch-mem
> >   posix/globtest
> 
> The elf/tst-sprof-basic seems to be a know issue based on 2.38 release
> wiki, and most of them seems also for related to the low TIMEOUTFACTOR.
> 
> >
> > Take master on lp4a as an example,
> >
> > - elf/tst-rtld-list-diagnostics, due to missing abnf module
> > - elf/tst-sprof-basic, successfully print hello world but return
> > status is 1, still unknown root cause
> > - elf/tst-tls-allocation-failure-static-patched, exec format error,
> > still unknown root cause
> 
> This seems to be a real regression, and I think you should sort this out
> before the patch is installed (I see no failure on qemu-user on master).
> The exec format error seems to come from kernel, due the execve failure;
> and might a corrupted binary.
> 
> > - the others are memory not freed
> >
> > The difference between qemu-system and lp4a for master is the two
> > cases,
> >
> > - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't
> investigated.
> 
> This might a unrelated issue [3], either in compiler optimization or due
> the the long-standing BZ#12683 issue.
> 
> > - posix/globtest, because my qemu-system has a different user name.
> >
> > The XFAILs and XPASSes are the same on all platforms and all branches.
> > So not list here.
> >
> > I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master
> branch.
> >
> > So is this the expected test result? Or is there still any case not
> correct FAIL or PASS?
> 
> I think the output look pretty ok, the only issue being the elf/tst-tls-
> allocation-failure-static failure.
> 
> 
> [1] https://sourceware.org/glibc/wiki/Release/2.38#RISC-
> V_.28rv64imac.2Flp64.29
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19329
> [3] https://sourceware.org/pipermail/libc-alpha/2019-
> September/106641.html

Re: [PATCH] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 24/10/23 02:59, Wang, Yanzhang wrote:
> Hi Adhemerval,
> 
> Thanks for your comments and the two categories cases are all figured out.
> 
> For the timed out cases, I increased the TIMEOUTFACTOR to 300 and finally passed.
> The 100 seems not working very well.

Excellent.

> 
> For the case elf/tst-tls-allocation-failure-static-patched, the root cause is it
> does not run with test-wrapper. I use cross-test-ssh.sh to run tests on the board.
> If no test-wrapper, it will run on my local. That's why exec format error.

Alright, so I don't have any further remarks for this patch.

> 
> I need to apply another patch below. Is it acceptable or I need to run the full
> test directly on board?
> 
> diff --git a/elf/Makefile b/elf/Makefile
> index 9176cbf1e3..1065b5c123 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -2979,7 +2979,7 @@ $(objpfx)tst-tls-allocation-failure-static-patched: \
> 
>  $(objpfx)tst-tls-allocation-failure-static-patched.out: \
>    $(objpfx)tst-tls-allocation-failure-static-patched
> -       $< > $@ 2>&1; echo "status: $$?" >> $@
> +       $(test-wrapper) $< > $@ 2>&1; echo "status: $$?" >> $@
>         grep -q '^Fatal glibc error: Cannot allocate TLS block$$' $@ \
>           && grep -q '^status: 127$$' $@; \
>           $(evaluate-test)

This would require to be in a different path, could you send it as well?

>  
> 
>> -----Original Message-----
>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>> Sent: Tuesday, October 17, 2023 9:42 PM
>> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
>> <palmer@dabbelt.com>
>> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
>> alpha@sourceware.org
>> Subject: Re: [PATCH] RISC-V: Enable static-pie.
>>
>>
>>
>> On 21/09/23 10:47, Wang, Yanzhang wrote:
>>> Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
>>> Your suggestions are so helpful to me.
>>>
>>> Yes. I also found this issue on GitHub too and the math failures
>>> didn't appear with QEMU system. So it's definitely a hardware bug.
>>>
>>> And I found the root cause of almost of the other failures. It's
>>> because I use sshfs not nfs. :( ..
>>
>> I don't have access to RISCV hardware, but we can use the 2.38 release [1]
>> as the baseline [1].
>>
>>>
>>> Even though I set a larger TIMEOUTFACTOR as you said, there're still
>>> some timeout failures like below. And seems the timeout is not stable.
>>> Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.
>>
>> The tst-stack4 was a long standing issue that should be fixed on master
>> [2].
>>
>>>
>>>   master with qemu-system       master on lp4a                static-
>> pie patch on lp4a
>>>  ----------------------------- ----------------------------- ----------
>> -------------------
>>>   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit
>> resolv/tst-resolv-res_ninit
>>>   nptl/tst-stack4               nptl/tst-stack4
>> iconvdata/tst-loading
>>>   libio/tst-fopenloc            libio/tst-fopenloc
>> localedata/tst-leaks
>>>   iconvdata/tst-loading         iconvdata/tst-loading
>> malloc/tst-dynarray-fail
>>>   localedata/tst-leaks          localedata/tst-leaks
>> posix/tst-fnmatch
>>>   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail
>>>   posix/tst-glob-tilde          posix/tst-glob-tilde
>>>   posix/tst-fnmatch             posix/tst-fnmatch
>>
>>
>> For static-pie I would focus on the *static* tests and check for any
>> regressions.
>> On the above, all are dynamic and most likely the timeout you have found
>> are due a low TIMEOUTFACTOR value.
>>
>> You can check by testing each one individually:
>>
>> $ TIMEOUTFACTOR=100 make test t=<test> # for instance, posix/tst-fnmatch
>>
>>>
>>> For the FAIL tests, it's like below. The math failures are filtered
>>> out on lp4a and not appear on qemu-system.
>>>
>>>   master with qemu-system                         master on lp4a
>> static-pie patch on lp4a
>>>  ----------------------------------------------- ----------------------
>> ------------------------- -----------------------------------------------
>>>   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-
>> resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit
>>>   nptl/tst-cancel21-static                        libio/tst-fopenloc-
>> mem                          elf/tst-tls-allocation-failure-static-
>> patched
>>>   libio/tst-fopenloc-mem                          libio/tst-fopenloc-
>> cmp                          elf/tst-rtld-list-diagnostics
>>>   libio/tst-fopenloc-cmp                          elf/tst-tls-
>> allocation-failure-static-patched   elf/tst-sprof-basic
>>>   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-
>> diagnostics                   iconvdata/mtrace-tst-loading
>>>   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic
>> localedata/mtrace-tst-leaks
>>>   elf/tst-sprof-basic                             iconvdata/mtrace-tst-
>> loading                    malloc/tst-dynarray-fail-mem
>>>   iconvdata/mtrace-tst-loading                    localedata/mtrace-
>> tst-leaks                     posix/tst-fnmatch-mem
>>>   localedata/mtrace-tst-leaks                     malloc/tst-dynarray-
>> fail-mem
>>>   malloc/tst-dynarray-fail-mem                    posix/tst-glob-tilde-
>> mem
>>>   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-mem
>>>   posix/tst-fnmatch-mem
>>>   posix/globtest
>>
>> The elf/tst-sprof-basic seems to be a know issue based on 2.38 release
>> wiki, and most of them seems also for related to the low TIMEOUTFACTOR.
>>
>>>
>>> Take master on lp4a as an example,
>>>
>>> - elf/tst-rtld-list-diagnostics, due to missing abnf module
>>> - elf/tst-sprof-basic, successfully print hello world but return
>>> status is 1, still unknown root cause
>>> - elf/tst-tls-allocation-failure-static-patched, exec format error,
>>> still unknown root cause
>>
>> This seems to be a real regression, and I think you should sort this out
>> before the patch is installed (I see no failure on qemu-user on master).
>> The exec format error seems to come from kernel, due the execve failure;
>> and might a corrupted binary.
>>
>>> - the others are memory not freed
>>>
>>> The difference between qemu-system and lp4a for master is the two
>>> cases,
>>>
>>> - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and haven't
>> investigated.
>>
>> This might a unrelated issue [3], either in compiler optimization or due
>> the the long-standing BZ#12683 issue.
>>
>>> - posix/globtest, because my qemu-system has a different user name.
>>>
>>> The XFAILs and XPASSes are the same on all platforms and all branches.
>>> So not list here.
>>>
>>> I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master
>> branch.
>>>
>>> So is this the expected test result? Or is there still any case not
>> correct FAIL or PASS?
>>
>> I think the output look pretty ok, the only issue being the elf/tst-tls-
>> allocation-failure-static failure.
>>
>>
>> [1] https://sourceware.org/glibc/wiki/Release/2.38#RISC-
>> V_.28rv64imac.2Flp64.29
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19329
>> [3] https://sourceware.org/pipermail/libc-alpha/2019-
>> September/106641.html

RE: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Of cause. I have sent it just now and cc you too.

> -----Original Message-----
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> Sent: Tuesday, October 24, 2023 7:39 PM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> <palmer@dabbelt.com>
> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>; libc-
> alpha@sourceware.org
> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> 
> 
> 
> On 24/10/23 02:59, Wang, Yanzhang wrote:
> > Hi Adhemerval,
> >
> > Thanks for your comments and the two categories cases are all figured
> out.
> >
> > For the timed out cases, I increased the TIMEOUTFACTOR to 300 and
> finally passed.
> > The 100 seems not working very well.
> 
> Excellent.
> 
> >
> > For the case elf/tst-tls-allocation-failure-static-patched, the root
> > cause is it does not run with test-wrapper. I use cross-test-ssh.sh to
> run tests on the board.
> > If no test-wrapper, it will run on my local. That's why exec format
> error.
> 
> Alright, so I don't have any further remarks for this patch.
> 
> >
> > I need to apply another patch below. Is it acceptable or I need to run
> > the full test directly on board?
> >
> > diff --git a/elf/Makefile b/elf/Makefile index 9176cbf1e3..1065b5c123
> > 100644
> > --- a/elf/Makefile
> > +++ b/elf/Makefile
> > @@ -2979,7 +2979,7 @@
> > $(objpfx)tst-tls-allocation-failure-static-patched: \
> >
> >  $(objpfx)tst-tls-allocation-failure-static-patched.out: \
> >    $(objpfx)tst-tls-allocation-failure-static-patched
> > -       $< > $@ 2>&1; echo "status: $$?" >> $@
> > +       $(test-wrapper) $< > $@ 2>&1; echo "status: $$?" >> $@
> >         grep -q '^Fatal glibc error: Cannot allocate TLS block$$' $@ \
> >           && grep -q '^status: 127$$' $@; \
> >           $(evaluate-test)
> 
> This would require to be in a different path, could you send it as well?
> 
> >
> >
> >> -----Original Message-----
> >> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> >> Sent: Tuesday, October 17, 2023 9:42 PM
> >> To: Wang, Yanzhang <yanzhang.wang@intel.com>; Palmer Dabbelt
> >> <palmer@dabbelt.com>
> >> Cc: DJ Delorie <dj@redhat.com>; Darius Rad <darius@bluespec.com>;
> >> libc- alpha@sourceware.org
> >> Subject: Re: [PATCH] RISC-V: Enable static-pie.
> >>
> >>
> >>
> >> On 21/09/23 10:47, Wang, Yanzhang wrote:
> >>> Thanks for all your comments, Palmer, DJ, Dairus and Adhemerval.
> >>> Your suggestions are so helpful to me.
> >>>
> >>> Yes. I also found this issue on GitHub too and the math failures
> >>> didn't appear with QEMU system. So it's definitely a hardware bug.
> >>>
> >>> And I found the root cause of almost of the other failures. It's
> >>> because I use sshfs not nfs. :( ..
> >>
> >> I don't have access to RISCV hardware, but we can use the 2.38
> >> release [1] as the baseline [1].
> >>
> >>>
> >>> Even though I set a larger TIMEOUTFACTOR as you said, there're still
> >>> some timeout failures like below. And seems the timeout is not stable.
> >>> Sometimes, nptl/tst-stack4 can pass on lp4a and sometimes not.
> >>
> >> The tst-stack4 was a long standing issue that should be fixed on
> >> master [2].
> >>
> >>>
> >>>   master with qemu-system       master on lp4a                static-
> >> pie patch on lp4a
> >>>  ----------------------------- -----------------------------
> >>> ----------
> >> -------------------
> >>>   resolv/tst-resolv-res_ninit   resolv/tst-resolv-res_ninit
> >> resolv/tst-resolv-res_ninit
> >>>   nptl/tst-stack4               nptl/tst-stack4
> >> iconvdata/tst-loading
> >>>   libio/tst-fopenloc            libio/tst-fopenloc
> >> localedata/tst-leaks
> >>>   iconvdata/tst-loading         iconvdata/tst-loading
> >> malloc/tst-dynarray-fail
> >>>   localedata/tst-leaks          localedata/tst-leaks
> >> posix/tst-fnmatch
> >>>   malloc/tst-dynarray-fail      malloc/tst-dynarray-fail
> >>>   posix/tst-glob-tilde          posix/tst-glob-tilde
> >>>   posix/tst-fnmatch             posix/tst-fnmatch
> >>
> >>
> >> For static-pie I would focus on the *static* tests and check for any
> >> regressions.
> >> On the above, all are dynamic and most likely the timeout you have
> >> found are due a low TIMEOUTFACTOR value.
> >>
> >> You can check by testing each one individually:
> >>
> >> $ TIMEOUTFACTOR=100 make test t=<test> # for instance,
> >> posix/tst-fnmatch
> >>
> >>>
> >>> For the FAIL tests, it's like below. The math failures are filtered
> >>> out on lp4a and not appear on qemu-system.
> >>>
> >>>   master with qemu-system                         master on lp4a
> >> static-pie patch on lp4a
> >>>  -----------------------------------------------
> >>> ----------------------
> >> -------------------------
> >> -----------------------------------------------
> >>>   resolv/mtrace-tst-resolv-res_ninit              resolv/mtrace-tst-
> >> resolv-res_ninit              resolv/mtrace-tst-resolv-res_ninit
> >>>   nptl/tst-cancel21-static                        libio/tst-fopenloc-
> >> mem                          elf/tst-tls-allocation-failure-static-
> >> patched
> >>>   libio/tst-fopenloc-mem                          libio/tst-fopenloc-
> >> cmp                          elf/tst-rtld-list-diagnostics
> >>>   libio/tst-fopenloc-cmp                          elf/tst-tls-
> >> allocation-failure-static-patched   elf/tst-sprof-basic
> >>>   elf/tst-tls-allocation-failure-static-patched   elf/tst-rtld-list-
> >> diagnostics                   iconvdata/mtrace-tst-loading
> >>>   elf/tst-rtld-list-diagnostics                   elf/tst-sprof-basic
> >> localedata/mtrace-tst-leaks
> >>>   elf/tst-sprof-basic                             iconvdata/mtrace-
> tst-
> >> loading                    malloc/tst-dynarray-fail-mem
> >>>   iconvdata/mtrace-tst-loading                    localedata/mtrace-
> >> tst-leaks                     posix/tst-fnmatch-mem
> >>>   localedata/mtrace-tst-leaks                     malloc/tst-
> dynarray-
> >> fail-mem
> >>>   malloc/tst-dynarray-fail-mem                    posix/tst-glob-
> tilde-
> >> mem
> >>>   posix/tst-glob-tilde-mem                        posix/tst-fnmatch-
> mem
> >>>   posix/tst-fnmatch-mem
> >>>   posix/globtest
> >>
> >> The elf/tst-sprof-basic seems to be a know issue based on 2.38
> >> release wiki, and most of them seems also for related to the low
> TIMEOUTFACTOR.
> >>
> >>>
> >>> Take master on lp4a as an example,
> >>>
> >>> - elf/tst-rtld-list-diagnostics, due to missing abnf module
> >>> - elf/tst-sprof-basic, successfully print hello world but return
> >>> status is 1, still unknown root cause
> >>> - elf/tst-tls-allocation-failure-static-patched, exec format error,
> >>> still unknown root cause
> >>
> >> This seems to be a real regression, and I think you should sort this
> >> out before the patch is installed (I see no failure on qemu-user on
> master).
> >> The exec format error seems to come from kernel, due the execve
> >> failure; and might a corrupted binary.
> >>
> >>> - the others are memory not freed
> >>>
> >>> The difference between qemu-system and lp4a for master is the two
> >>> cases,
> >>>
> >>> - nptl/tst-cancel21-static, it said sa_flags = SA_ONSTACK and
> >>> haven't
> >> investigated.
> >>
> >> This might a unrelated issue [3], either in compiler optimization or
> >> due the the long-standing BZ#12683 issue.
> >>
> >>> - posix/globtest, because my qemu-system has a different user name.
> >>>
> >>> The XFAILs and XPASSes are the same on all platforms and all branches.
> >>> So not list here.
> >>>
> >>> I use the commit 4be913652ca115160bae1daf560170ef8b112ccb of master
> >> branch.
> >>>
> >>> So is this the expected test result? Or is there still any case not
> >> correct FAIL or PASS?
> >>
> >> I think the output look pretty ok, the only issue being the
> >> elf/tst-tls- allocation-failure-static failure.
> >>
> >>
> >> [1] https://sourceware.org/glibc/wiki/Release/2.38#RISC-
> >> V_.28rv64imac.2Flp64.29
> >> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19329
> >> [3] https://sourceware.org/pipermail/libc-alpha/2019-
> >> September/106641.html

Re: [PATCH] RISC-V: Enable static-pie.

[Carlos O'Donell]

On 8/10/23 19:33, yanzhang.wang--- via Libc-alpha wrote:
> From: Yanzhang Wang <yanzhang.wang@intel.com>
> 
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.

This fails pre-commit CI.

https://patchwork.sourceware.org/project/glibc/patch/20230810233348.1214955-1-yanzhang.wang@intel.com/

Patch conflict in configure. Please make sure you are regenerating properly.


> ---
>  sysdeps/riscv/configure    | 2 ++
>  sysdeps/riscv/configure.ac | 3 +++
>  sysdeps/riscv/dl-machine.h | 2 +-
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
> index 2372225a26..340163779f 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -29,3 +29,5 @@ fi
>  $as_echo "$libc_cv_riscv_r_align" >&6; }
>  config_vars="$config_vars
>  riscv-r-align = $libc_cv_riscv_r_align"
> +
> +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> index dbcc216689..36da2b5396 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,6 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Static PIE is supported.
> +AC_DEFINE(SUPPORT_STATIC_PIE)
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index c0c9bd93ad..ad875c0828 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>  
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>  	 $gp register does not be used to access the global variable

-- 
Cheers,
Carlos.

Re: [PATCH] RISC-V: Enable static-pie.

[Wang, Yanzhang]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

Hi Carlos,

Sorry for the inconvenience.

I have pushed a new patch and should be right now.

Thanks,
Yanzhang
________________________________
From: Carlos O'Donell <carlos@redhat.com>
Sent: Monday, August 14, 2023 9:12 PM
To: Wang, Yanzhang <yanzhang.wang@intel.com>; libc-alpha@sourceware.org <libc-alpha@sourceware.org>
Subject: Re: [PATCH] RISC-V: Enable static-pie.

On 8/10/23 19:33, yanzhang.wang--- via Libc-alpha wrote:
> From: Yanzhang Wang <yanzhang.wang@intel.com>
>
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.

This fails pre-commit CI.

https://patchwork.sourceware.org/project/glibc/patch/20230810233348.1214955-1-yanzhang.wang@intel.com/

Patch conflict in configure. Please make sure you are regenerating properly.


> ---
>  sysdeps/riscv/configure    | 2 ++
>  sysdeps/riscv/configure.ac | 3 +++
>  sysdeps/riscv/dl-machine.h | 2 +-
>  3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
> index 2372225a26..340163779f 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -29,3 +29,5 @@ fi
>  $as_echo "$libc_cv_riscv_r_align" >&6; }
>  config_vars="$config_vars
>  riscv-r-align = $libc_cv_riscv_r_align"
> +
> +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> index dbcc216689..36da2b5396 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,6 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Static PIE is supported.
> +AC_DEFINE(SUPPORT_STATIC_PIE)
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index c0c9bd93ad..ad875c0828 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>         $gp register does not be used to access the global variable

--
Cheers,
Carlos.

[PATCH v2] RISC-V: Enable static-pie.

[yanzhang.wang]

From: Yanzhang Wang <yanzhang.wang@intel.com>

This patch referents the commit 374cef3 to add static-pie support. And
because the dummy link map is used when relocating ourselves, so need
not to set __global_pointer$ at this time.
---
 sysdeps/riscv/configure    | 1 +
 sysdeps/riscv/configure.ac | 3 +++
 sysdeps/riscv/dl-machine.h | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
index acd1f5e743..ecaf8e2a0b 100644
--- a/sysdeps/riscv/configure
+++ b/sysdeps/riscv/configure
@@ -31,3 +31,4 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
 config_vars="$config_vars
 riscv-r-align = $libc_cv_riscv_r_align"
 
+$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
index dbcc216689..36da2b5396 100644
--- a/sysdeps/riscv/configure.ac
+++ b/sysdeps/riscv/configure.ac
@@ -16,3 +16,6 @@ EOF
   fi
   rm -rf conftest.*])
 LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
+
+dnl Static PIE is supported.
+AC_DEFINE(SUPPORT_STATIC_PIE)
diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
index c0c9bd93ad..ad875c0828 100644
--- a/sysdeps/riscv/dl-machine.h
+++ b/sysdeps/riscv/dl-machine.h
@@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
       gotplt[1] = (ElfW(Addr)) l;
     }
 
-  if (l->l_type == lt_executable)
+  if (l->l_type == lt_executable && l->l_scope != NULL)
     {
       /* The __global_pointer$ may not be defined by the linker if the
 	 $gp register does not be used to access the global variable
-- 
2.41.0

RE: [PATCH v2] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Hi,

We have a lot talks about this patch sometimes ago at 
https://patchwork.sourceware.org/project/glibc/patch/20230810233348.1214955-1-yanzhang.wang@intel.com/.
It mainly focus on the regression test of this feature. I did some tests
as the mail shows. And based on the results, it seems no regression
introduced by this patch.

I think I got one approve from Adhemerval. Is there any further comments?
What do I need to do next step to get this patch be merged?

Thanks,
Yanzhang

> -----Original Message-----
> From: Wang, Yanzhang <yanzhang.wang@intel.com>
> Sent: Tuesday, August 15, 2023 9:45 AM
> To: libc-alpha@sourceware.org
> Cc: carlos@redhat.com; palmer@dabbelt.com; Wang, Yanzhang
> <yanzhang.wang@intel.com>
> Subject: [PATCH v2] RISC-V: Enable static-pie.
> 
> From: Yanzhang Wang <yanzhang.wang@intel.com>
> 
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need not
> to set __global_pointer$ at this time.
> ---
>  sysdeps/riscv/configure    | 1 +
>  sysdeps/riscv/configure.ac | 3 +++
>  sysdeps/riscv/dl-machine.h | 2 +-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure index
> acd1f5e743..ecaf8e2a0b 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -31,3 +31,4 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
> config_vars="$config_vars  riscv-r-align = $libc_cv_riscv_r_align"
> 
> +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac index
> dbcc216689..36da2b5396 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,6 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Static PIE is supported.
> +AC_DEFINE(SUPPORT_STATIC_PIE)
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h index
> c0c9bd93ad..ad875c0828 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct
> r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
> 
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>  	 $gp register does not be used to access the global variable
> --
> 2.41.0

Re: [PATCH v2] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 14/08/23 22:44, yanzhang.wang--- via Libc-alpha wrote:
> From: Yanzhang Wang <yanzhang.wang@intel.com>
> 
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.

To enable this support as default woudl equires GCC commit 
b20e59f49b51b7baf05e1b727be5da947e617496 that pass the expected ld flags. 
Otherwise, building static-pie will fail with missing _DYNAMIC:

riscv64-glibc-linux-gnu-gcc -o [...] support/test-run-command -nostdlib -nostartfiles -static -static-pie [...]
[...]libc.a(dl-reloc-static-pie.o): in function `_dl_relocate_static_pie':
[...]elf/dl-reloc-static-pie.c:48: undefined reference to `_DYNAMIC' 

I think you will need to add something similar to what loongarch did on 
sysdeps/loongarch/configure.ac and check whether compile do actually 
supports -static-pie.

> ---
>  sysdeps/riscv/configure    | 1 +
>  sysdeps/riscv/configure.ac | 3 +++
>  sysdeps/riscv/dl-machine.h | 2 +-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
> index acd1f5e743..ecaf8e2a0b 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -31,3 +31,4 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
>  config_vars="$config_vars
>  riscv-r-align = $libc_cv_riscv_r_align"
>  
> +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> index dbcc216689..36da2b5396 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,6 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Static PIE is supported.
> +AC_DEFINE(SUPPORT_STATIC_PIE)
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index c0c9bd93ad..ad875c0828 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>  
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>  	 $gp register does not be used to access the global variable

RE: [PATCH v2] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Thanks for pointing this out. Yes, I should do the verification. I have
pushed a new patch (patch v3) just now and verified with two version's 
gcc (support and not support). Please help to review it.

Thanks,
Yanzhang

> -----Original Message-----
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> Sent: Wednesday, December 20, 2023 1:44 AM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>; libc-alpha@sourceware.org
> Cc: carlos@redhat.com; palmer@dabbelt.com
> Subject: Re: [PATCH v2] RISC-V: Enable static-pie.
> 
> 
> 
> On 14/08/23 22:44, yanzhang.wang--- via Libc-alpha wrote:
> > From: Yanzhang Wang <yanzhang.wang@intel.com>
> >
> > This patch referents the commit 374cef3 to add static-pie support. And
> > because the dummy link map is used when relocating ourselves, so need
> > not to set __global_pointer$ at this time.
> 
> To enable this support as default woudl equires GCC commit
> b20e59f49b51b7baf05e1b727be5da947e617496 that pass the expected ld flags.
> Otherwise, building static-pie will fail with missing _DYNAMIC:
> 
> riscv64-glibc-linux-gnu-gcc -o [...] support/test-run-command -nostdlib -
> nostartfiles -static -static-pie [...]
> [...]libc.a(dl-reloc-static-pie.o): in function `_dl_relocate_static_pie':
> [...]elf/dl-reloc-static-pie.c:48: undefined reference to `_DYNAMIC'
> 
> I think you will need to add something similar to what loongarch did on
> sysdeps/loongarch/configure.ac and check whether compile do actually
> supports -static-pie.
> 
> > ---
> >  sysdeps/riscv/configure    | 1 +
> >  sysdeps/riscv/configure.ac | 3 +++
> >  sysdeps/riscv/dl-machine.h | 2 +-
> >  3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure index
> > acd1f5e743..ecaf8e2a0b 100644
> > --- a/sysdeps/riscv/configure
> > +++ b/sysdeps/riscv/configure
> > @@ -31,3 +31,4 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
> > config_vars="$config_vars  riscv-r-align = $libc_cv_riscv_r_align"
> >
> > +$as_echo "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> > diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> > index dbcc216689..36da2b5396 100644
> > --- a/sysdeps/riscv/configure.ac
> > +++ b/sysdeps/riscv/configure.ac
> > @@ -16,3 +16,6 @@ EOF
> >    fi
> >    rm -rf conftest.*])
> >  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> > +
> > +dnl Static PIE is supported.
> > +AC_DEFINE(SUPPORT_STATIC_PIE)
> > diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> > index c0c9bd93ad..ad875c0828 100644
> > --- a/sysdeps/riscv/dl-machine.h
> > +++ b/sysdeps/riscv/dl-machine.h
> > @@ -323,7 +323,7 @@ elf_machine_runtime_setup (struct link_map *l,
> struct r_scope_elem *scope[],
> >        gotplt[1] = (ElfW(Addr)) l;
> >      }
> >
> > -  if (l->l_type == lt_executable)
> > +  if (l->l_type == lt_executable && l->l_scope != NULL)
> >      {
> >        /* The __global_pointer$ may not be defined by the linker if the
> >  	 $gp register does not be used to access the global variable

[PATCH v3] RISC-V: Enable static-pie.

[yanzhang.wang]

From: Yanzhang Wang <yanzhang.wang@intel.com>

This patch referents the commit 374cef3 to add static-pie support. And
because the dummy link map is used when relocating ourselves, so need
not to set __global_pointer$ at this time.

It will also check whether toolchain supports to build static-pie.
---
 sysdeps/riscv/configure    | 49 ++++++++++++++++++++++++++++++++++++++
 sysdeps/riscv/configure.ac | 27 +++++++++++++++++++++
 sysdeps/riscv/dl-machine.h |  2 +-
 3 files changed, 77 insertions(+), 1 deletion(-)

diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
index acd1f5e743..c8f01709f8 100644
--- a/sysdeps/riscv/configure
+++ b/sysdeps/riscv/configure
@@ -31,3 +31,52 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
 config_vars="$config_vars
 riscv-r-align = $libc_cv_riscv_r_align"
 
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking if the toolchain is sufficient to build static PIE on RISC-V" >&5
+printf %s "checking if the toolchain is sufficient to build static PIE on RISC-V... " >&6; }
+if test ${libc_cv_static_pie_on_riscv+y}
+then :
+  printf %s "(cached) " >&6
+else $as_nop
+
+  cat > conftest1.S <<\EOF
+    .globl _start
+    .type   _start, @function
+_start:
+    nop
+
+    .data
+    /* This should produce an R_RISCV_RELATIVE in the static PIE.  */
+    .dword      _start
+EOF
+
+  libc_cv_static_pie_on_riscv=no
+  if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; } \
+     && { ac_try='LC_ALL=C $READELF -Wr conftest1 | grep -q R_RISCV_RELATIVE'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; } \
+     && ! { ac_try='LC_ALL=C $READELF -Wl conftest1 | grep -q INTERP'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+  then
+    libc_cv_static_pie_on_riscv=yes
+  fi
+  rm -rf conftest*
+fi
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_static_pie_on_riscv" >&5
+printf "%s\n" "$libc_cv_static_pie_on_riscv" >&6; }
+
+if test "$libc_cv_static_pie_on_riscv" = yes; then
+  printf "%s\n" "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
+
+fi
diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
index dbcc216689..ee3d1ed014 100644
--- a/sysdeps/riscv/configure.ac
+++ b/sysdeps/riscv/configure.ac
@@ -16,3 +16,30 @@ EOF
   fi
   rm -rf conftest.*])
 LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
+
+dnl Test if the toolchain is new enough for static PIE.
+AC_CACHE_CHECK([if the toolchain is sufficient to build static PIE on RISC-V],
+libc_cv_static_pie_on_riscv, [
+  cat > conftest1.S <<\EOF
+    .globl _start
+    .type   _start, @function
+_start:
+    nop
+
+    .data
+    /* This should produce an R_RISCV_RELATIVE in the static PIE.  */
+    .dword      _start
+EOF
+
+  libc_cv_static_pie_on_riscv=no
+  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S]) \
+     && AC_TRY_COMMAND([LC_ALL=C $READELF -Wr conftest1 | grep -q R_RISCV_RELATIVE]) \
+     && ! AC_TRY_COMMAND([LC_ALL=C $READELF -Wl conftest1 | grep -q INTERP])
+  then
+    libc_cv_static_pie_on_riscv=yes
+  fi
+  rm -rf conftest* ])
+
+if test "$libc_cv_static_pie_on_riscv" = yes; then
+  AC_DEFINE(SUPPORT_STATIC_PIE)
+fi
diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
index ffb8c4aaa0..0cbb476c05 100644
--- a/sysdeps/riscv/dl-machine.h
+++ b/sysdeps/riscv/dl-machine.h
@@ -348,7 +348,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
       gotplt[1] = (ElfW(Addr)) l;
     }
 
-  if (l->l_type == lt_executable)
+  if (l->l_type == lt_executable && l->l_scope != NULL)
     {
       /* The __global_pointer$ may not be defined by the linker if the
 	 $gp register does not be used to access the global variable
-- 
2.42.1

Re: [PATCH v3] RISC-V: Enable static-pie.

[Adhemerval Zanella Netto]

On 02/01/24 07:54, yanzhang.wang@intel.com wrote:
> From: Yanzhang Wang <yanzhang.wang@intel.com>
> 
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.
> 
> It will also check whether toolchain supports to build static-pie.

LGTM, thanks.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> ---
>  sysdeps/riscv/configure    | 49 ++++++++++++++++++++++++++++++++++++++
>  sysdeps/riscv/configure.ac | 27 +++++++++++++++++++++
>  sysdeps/riscv/dl-machine.h |  2 +-
>  3 files changed, 77 insertions(+), 1 deletion(-)
> 
> diff --git a/sysdeps/riscv/configure b/sysdeps/riscv/configure
> index acd1f5e743..c8f01709f8 100644
> --- a/sysdeps/riscv/configure
> +++ b/sysdeps/riscv/configure
> @@ -31,3 +31,52 @@ printf "%s\n" "$libc_cv_riscv_r_align" >&6; }
>  config_vars="$config_vars
>  riscv-r-align = $libc_cv_riscv_r_align"
>  
> +{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking if the toolchain is sufficient to build static PIE on RISC-V" >&5
> +printf %s "checking if the toolchain is sufficient to build static PIE on RISC-V... " >&6; }
> +if test ${libc_cv_static_pie_on_riscv+y}
> +then :
> +  printf %s "(cached) " >&6
> +else $as_nop
> +
> +  cat > conftest1.S <<\EOF
> +    .globl _start
> +    .type   _start, @function
> +_start:
> +    nop
> +
> +    .data
> +    /* This should produce an R_RISCV_RELATIVE in the static PIE.  */
> +    .dword      _start
> +EOF
> +
> +  libc_cv_static_pie_on_riscv=no
> +  if { ac_try='${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; } \
> +     && { ac_try='LC_ALL=C $READELF -Wr conftest1 | grep -q R_RISCV_RELATIVE'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; } \
> +     && ! { ac_try='LC_ALL=C $READELF -Wl conftest1 | grep -q INTERP'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  printf "%s\n" "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; }
> +  then
> +    libc_cv_static_pie_on_riscv=yes
> +  fi
> +  rm -rf conftest*
> +fi
> +{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_static_pie_on_riscv" >&5
> +printf "%s\n" "$libc_cv_static_pie_on_riscv" >&6; }
> +
> +if test "$libc_cv_static_pie_on_riscv" = yes; then
> +  printf "%s\n" "#define SUPPORT_STATIC_PIE 1" >>confdefs.h
> +
> +fi
> diff --git a/sysdeps/riscv/configure.ac b/sysdeps/riscv/configure.ac
> index dbcc216689..ee3d1ed014 100644
> --- a/sysdeps/riscv/configure.ac
> +++ b/sysdeps/riscv/configure.ac
> @@ -16,3 +16,30 @@ EOF
>    fi
>    rm -rf conftest.*])
>  LIBC_CONFIG_VAR([riscv-r-align], [$libc_cv_riscv_r_align])
> +
> +dnl Test if the toolchain is new enough for static PIE.
> +AC_CACHE_CHECK([if the toolchain is sufficient to build static PIE on RISC-V],
> +libc_cv_static_pie_on_riscv, [
> +  cat > conftest1.S <<\EOF
> +    .globl _start
> +    .type   _start, @function
> +_start:
> +    nop
> +
> +    .data
> +    /* This should produce an R_RISCV_RELATIVE in the static PIE.  */
> +    .dword      _start
> +EOF
> +
> +  libc_cv_static_pie_on_riscv=no
> +  if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS -static-pie -nostdlib -fPIE -o conftest1 conftest1.S]) \
> +     && AC_TRY_COMMAND([LC_ALL=C $READELF -Wr conftest1 | grep -q R_RISCV_RELATIVE]) \
> +     && ! AC_TRY_COMMAND([LC_ALL=C $READELF -Wl conftest1 | grep -q INTERP])
> +  then
> +    libc_cv_static_pie_on_riscv=yes
> +  fi
> +  rm -rf conftest* ])
> +
> +if test "$libc_cv_static_pie_on_riscv" = yes; then
> +  AC_DEFINE(SUPPORT_STATIC_PIE)
> +fi
> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index ffb8c4aaa0..0cbb476c05 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -348,7 +348,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>  
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)
>      {
>        /* The __global_pointer$ may not be defined by the linker if the
>  	 $gp register does not be used to access the global variable

Re: [PATCH v3] RISC-V: Enable static-pie.

[Andreas Schwab]

On Jan 02 2024, yanzhang.wang@intel.com wrote:

> From: Yanzhang Wang <yanzhang.wang@intel.com>
>
> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.
>
> It will also check whether toolchain supports to build static-pie.

How did you check that?  It doesn't work here:

Breakpoint 1, _start () at ../sysdeps/riscv/start.S:50
50              call  load_gp
1: x/i $pc
=> 0x3ff7f59ea4 <_start>:       jal     0x3ff7f59ec6 <load_gp>
(gdb) ni
_start () at ../sysdeps/riscv/start.S:74
74              lla   gp, __global_pointer$
1: x/i $pc
=> 0x3ff7f59ec6 <load_gp>:      auipc   gp,0xa0
(gdb) 
0x0000003ff7f59eca      74              lla   gp, __global_pointer$
1: x/i $pc
=> 0x3ff7f59eca <_start+38>:    add     gp,gp,706
(gdb) 
load_gp () at ../sysdeps/riscv/start.S:76
76              ret
1: x/i $pc
=> 0x3ff7f59ece <load_gp+8>:    ret
(gdb) 
_start () at ../sysdeps/riscv/start.S:51
51              mv    a5, a0  /* rtld_fini.  */
1: x/i $pc
=> 0x3ff7f59ea8 <_start+4>:     mv      a5,a0
(gdb) 
53              la   a0, main
1: x/i $pc
=> 0x3ff7f59eaa <_start+6>:     auipc   a0,0x9e
(gdb) 
0x0000003ff7f59eae      53              la   a0, main
1: x/i $pc
=> 0x3ff7f59eae <_start+10>:    ld      a0,-74(a0)
(gdb) 
54              REG_L a1, 0(sp)      /* argc.  */
1: x/i $pc
=> 0x3ff7f59eb2 <_start+14>:    ld      a1,0(sp)
(gdb) i reg a0
a0             0x0      0

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH v3] RISC-V: Enable static-pie.

[Andreas Schwab]

On Jan 02 2024, yanzhang.wang@intel.com wrote:

> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> index ffb8c4aaa0..0cbb476c05 100644
> --- a/sysdeps/riscv/dl-machine.h
> +++ b/sysdeps/riscv/dl-machine.h
> @@ -348,7 +348,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
>        gotplt[1] = (ElfW(Addr)) l;
>      }
>  
> -  if (l->l_type == lt_executable)
> +  if (l->l_type == lt_executable && l->l_scope != NULL)

This is not the right way to test for static PIE, it tries to access a
non-relocated non-zero pointer.  The mold linker, when producing
relative relocations, puts the addend both in the relocation addend and
the relocated field, which is perfectly valid to do, so this is non-zero
here.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

RE: [PATCH v3] RISC-V: Enable static-pie.

[Wang, Yanzhang]

Hi Andreas,

Sorry for the late response. Thanks your comments! And I don't quite
follow your comments. Could you please give some further information?

> (gdb) ni
> _start () at ../sysdeps/riscv/start.S:74
> 74              lla   gp, __global_pointer$
> 1: x/i $pc
> => 0x3ff7f59ec6 <load_gp>:      auipc   gp,0xa0
> (gdb)
> 0x0000003ff7f59eca      74              lla   gp, __global_pointer$
> 1: x/i $pc
> => 0x3ff7f59eca <_start+38>:    add     gp,gp,706
> (gdb)
> load_gp () at ../sysdeps/riscv/start.S:76
> 76              ret
> 1: x/i $pc
> => 0x3ff7f59ece <load_gp+8>:    ret
> (gdb)
> _start () at ../sysdeps/riscv/start.S:51
> 51              mv    a5, a0  /* rtld_fini.  */
> 1: x/i $pc
> => 0x3ff7f59ea8 <_start+4>:     mv      a5,a0
> (gdb)
> 53              la   a0, main
> 1: x/i $pc
> => 0x3ff7f59eaa <_start+6>:     auipc   a0,0x9e
> (gdb)
> 0x0000003ff7f59eae      53              la   a0, main
> 1: x/i $pc
> => 0x3ff7f59eae <_start+10>:    ld      a0,-74(a0)
> (gdb)
> 54              REG_L a1, 0(sp)      /* argc.  */
> 1: x/i $pc
> => 0x3ff7f59eb2 <_start+14>:    ld      a1,0(sp)
> (gdb) i reg a0
> a0             0x0      0

The first, it seems you have constructed a test case which should fail
this patch. But based on your gdb comment, I'm not sure which step is
not correct. Should the a0 register be non-zero or the gp register be
wrong? 

---

The code in the if will try to lookup the __global_pointer$ and move to the
gp register. It will be failed because l->l_scope is NULL when static-pie.
So I added this checking to avoid this failure.

> > +  if (l->l_type == lt_executable && l->l_scope != NULL)


> This is not the right way to test for static PIE, it tries to access a
> non-relocated non-zero pointer.  The mold linker, when producing relative
> relocations, puts the addend both in the relocation addend and the
> relocated field, which is perfectly valid to do, so this is non-zero here.

The second, do you mean there's a case that l->l_scope is not NULL when built
with static-pie? Or we should not access the members in link_map ?

Thanks,
Yanzhang

> -----Original Message-----
> From: Andreas Schwab <schwab@suse.de>
> Sent: Monday, January 29, 2024 8:46 PM
> To: Wang, Yanzhang <yanzhang.wang@intel.com>
> Cc: libc-alpha@sourceware.org; adhemerval.zanella@linaro.org
> Subject: Re: [PATCH v3] RISC-V: Enable static-pie.
> 
> On Jan 02 2024, yanzhang.wang@intel.com wrote:
> 
> > diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> > index ffb8c4aaa0..0cbb476c05 100644
> > --- a/sysdeps/riscv/dl-machine.h
> > +++ b/sysdeps/riscv/dl-machine.h
> > @@ -348,7 +348,7 @@ elf_machine_runtime_setup (struct link_map *l,
> struct r_scope_elem *scope[],
> >        gotplt[1] = (ElfW(Addr)) l;
> >      }
> >
> > -  if (l->l_type == lt_executable)
> > +  if (l->l_type == lt_executable && l->l_scope != NULL)
> 
> This is not the right way to test for static PIE, it tries to access a
> non-relocated non-zero pointer.  The mold linker, when producing relative
> relocations, puts the addend both in the relocation addend and the
> relocated field, which is perfectly valid to do, so this is non-zero here.
> 
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8
> 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."

Re: [PATCH v3] RISC-V: Enable static-pie.

[Andreas Schwab]

On Feb 01 2024, Wang, Yanzhang wrote:

> The code in the if will try to lookup the __global_pointer$ and move to the
> gp register. It will be failed because l->l_scope is NULL when static-pie.

No, l->l_scope is an unrelocated pointer.  Since ld.mold puts the addend
also in the relocated field, it is read as a nonzero, but invalid
pointer.  See the static-pie tests in the mold testsuite.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH v3] RISC-V: Enable static-pie.

[Maciej W. Rozycki]

On Tue, 2 Jan 2024, yanzhang.wang@intel.com wrote:

> This patch referents the commit 374cef3 to add static-pie support. And
> because the dummy link map is used when relocating ourselves, so need
> not to set __global_pointer$ at this time.
> 
> It will also check whether toolchain supports to build static-pie.

 Somehow the check fails to trigger here, causing a build error:

riscv64-linux-gnu-gcc  -o .../support/test-run-command -nostdlib -nostartfiles -static -static-pie     .../csu/rcrt1.o .../csu/crti.o `riscv64-linux-gnu-gcc   --print-file-name=crtbeginS.o` .../support/test-run-command.o .../elf/static-stubs.o .../support/libsupport_nonshared.a  -Wl,--start-group .../libc.a -lgcc  -Wl,--end-group `riscv64-linux-gnu-gcc   --print-file-name=crtendS.o` .../csu/crtn.o.../bin/../lib/gcc/riscv64-linux-gnu/14.0.0/../../../../riscv64-linux-gnu/bin/ld: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit status
make[2]: *** [../Rules:290: .../support/test-run-command] Error 1

I have filed BZ #31773.

  Maciej