unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* error when running "make bench"
@ 2020-01-15 16:55 paul zimmermann
  2020-01-15 17:33 ` Carlos O'Donell
  0 siblings, 1 reply; 9+ messages in thread
From: paul zimmermann @ 2020-01-15 16:55 UTC (permalink / raw)
  To: libc-alpha

       Hi,

with git revision a8f0fc4, when running "make bench" on my machine
(x86_64 under Linux), I get just before the math tests start:

...
/bin/sh: 2: /tmp/glibc/build/benchtests/bench-timing-type: not found
Running /tmp/glibc/build/benchtests/bench-acos
Running /tmp/glibc/build/benchtests/bench-acosh
...

Is the "not found" message normal?

Best regards,
Paul Zimmermann

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-15 16:55 error when running "make bench" paul zimmermann
@ 2020-01-15 17:33 ` Carlos O'Donell
  2020-01-16  6:57   ` paul zimmermann
  0 siblings, 1 reply; 9+ messages in thread
From: Carlos O'Donell @ 2020-01-15 17:33 UTC (permalink / raw)
  To: paul zimmermann; +Cc: GNU C Library

On Wed, Jan 15, 2020 at 12:02 PM paul zimmermann
<Paul.Zimmermann@inria.fr> wrote:
> with git revision a8f0fc4, when running "make bench" on my machine

What branch has that commit?

> (x86_64 under Linux), I get just before the math tests start:
>
> ...
> /bin/sh: 2: /tmp/glibc/build/benchtests/bench-timing-type: not found

This is a binary that should have been built for you which returns the
timing type to use.

[carlos@athas glibc]$ /home/carlos/build/glibc/benchtests/bench-timing-type
hp_timing

> Running /tmp/glibc/build/benchtests/bench-acos
> Running /tmp/glibc/build/benchtests/bench-acosh
> ...
>
> Is the "not found" message normal?

No. It works just fine for me.

Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-15 17:33 ` Carlos O'Donell
@ 2020-01-16  6:57   ` paul zimmermann
  2020-01-16  9:27     ` Szabolcs Nagy
  0 siblings, 1 reply; 9+ messages in thread
From: paul zimmermann @ 2020-01-16  6:57 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: libc-alpha

       Dear Carlos,

> From: "Carlos O'Donell" <carlos@redhat.com>
> Date: Wed, 15 Jan 2020 12:33:01 -0500
> 
> On Wed, Jan 15, 2020 at 12:02 PM paul zimmermann
> <Paul.Zimmermann@inria.fr> wrote:
> > with git revision a8f0fc4, when running "make bench" on my machine
> 
> What branch has that commit?

it is branch "master":

commit a8f0fc4e5fbad300d524a3339d503c41e3182ed0 (HEAD -> master, origin/master, origin/HEAD)
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Mon Jan 13 20:41:07 2020 +0100

    htl: Add internal version of __pthread_mutex_timedlock
    
    The C11 threads implementation will need it.

> > (x86_64 under Linux), I get just before the math tests start:
> >
> > ...
> > /bin/sh: 2: /tmp/glibc/build/benchtests/bench-timing-type: not found
> 
> This is a binary that should have been built for you which returns the
> timing type to use.
> 
> [carlos@athas glibc]$ /home/carlos/build/glibc/benchtests/bench-timing-type
> hp_timing
> 
> > Running /tmp/glibc/build/benchtests/bench-acos
> > Running /tmp/glibc/build/benchtests/bench-acosh
> > ...
> >
> > Is the "not found" message normal?
> 
> No. It works just fine for me.

what is strange is that the file exists:

$ ls -l /tmp/glibc/build/benchtests/bench-timing-type
-rwxr-xr-x 1 zimmerma caramba 35760 Jan 16 07:48 /tmp/glibc/build/benchtests/bench-timing-type

$ file /tmp/glibc/build/benchtests/bench-timing-type
/tmp/glibc/build/benchtests/bench-timing-type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /tmp/lib/ld-linux-x86-64.so.2, BuildID[sha1]=6eaee68beda7ba9d3a4e7c329d427b5c0676483d, for GNU/Linux 3.2.0, with debug_info, not stripped

however it does not want to run:

$ /tmp/glibc/build/benchtests/bench-timing-type
-bash: /tmp/glibc/build/benchtests/bench-timing-type: No such file or directory

Anyway this does not prevent "make bench" to run.

Paul Zimmermann

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-16  6:57   ` paul zimmermann
@ 2020-01-16  9:27     ` Szabolcs Nagy
  2020-01-16 10:34       ` paul zimmermann
  0 siblings, 1 reply; 9+ messages in thread
From: Szabolcs Nagy @ 2020-01-16  9:27 UTC (permalink / raw)
  To: paul zimmermann, Carlos O'Donell; +Cc: nd, libc-alpha@sourceware.org

On 16/01/2020 06:57, paul zimmermann wrote:
> what is strange is that the file exists:
> 
> $ ls -l /tmp/glibc/build/benchtests/bench-timing-type
> -rwxr-xr-x 1 zimmerma caramba 35760 Jan 16 07:48 /tmp/glibc/build/benchtests/bench-timing-type
> 
> $ file /tmp/glibc/build/benchtests/bench-timing-type
> /tmp/glibc/build/benchtests/bench-timing-type: ELF 64-bit LSB shared object,
> x86-64, version 1 (SYSV), dynamically linked, interpreter /tmp/lib/ld-linux-x86-64.so.2,
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> BuildID[sha1]=6eaee68beda7ba9d3a4e7c329d427b5c0676483d, for GNU/Linux 3.2.0, with debug_info, not stripped
> 
> however it does not want to run:
> 
> $ /tmp/glibc/build/benchtests/bench-timing-type
> -bash: /tmp/glibc/build/benchtests/bench-timing-type: No such file or directory

that executable seems to be built with

 -Wl,-dynamic-linker=/tmp/lib/ld-linux-x86-64.so.2

which does not exist, you can quickly fix it now
by making that a symlink to wherever the dynamic
linker is (and set up runtime library paths where
libc.so.6 etc is)

but i think ideally your host toolchain should
not produce executables that cannot run.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-16  9:27     ` Szabolcs Nagy
@ 2020-01-16 10:34       ` paul zimmermann
  2020-01-16 16:31         ` Joseph Myers
  0 siblings, 1 reply; 9+ messages in thread
From: paul zimmermann @ 2020-01-16 10:34 UTC (permalink / raw)
  To: Szabolcs Nagy; +Cc: carlos, nd, libc-alpha

thank you Szabolcs, this solved the problem.

However, I believe the issue is on the glibc side. Indeed, the
bench-timing-type is linked with /tmp/lib/ld-linux-x86-64.so.2
by the glibc Makefile, and that file doesn't exist if "make install"
was not done (I configured with ./configure --prefix=/tmp).

Thus either benchtests/README should indicate that "make install" should
be done, or the compile line for bench-timing-type should not link with
files in $PREFIX.

To reproduce:

$ git clone git://sourceware.org/git/glibc.git
$ cd glibc
$ mkdir build
$ cd build
$ ../configure --prefix=/tmp
$ make -j4
$ make bench

Best regards,
Paul

> From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
> CC: nd <nd@arm.com>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
> Thread-Topic: error when running "make bench"
> Thread-Index: AQHVy8STAjP+xHdPFUeTg1WXkdE96Kfr/CKAgADg6e+AACnCAA==
> Date: Thu, 16 Jan 2020 09:27:36 +0000
> user-agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101
>  Thunderbird/60.9.0
> nodisclaimer: True
> Original-Authentication-Results: spf=none (sender IP is )
>  smtp.mailfrom=Szabolcs.Nagy@arm.com; 
> 
> On 16/01/2020 06:57, paul zimmermann wrote:
> > what is strange is that the file exists:
> > 
> > $ ls -l /tmp/glibc/build/benchtests/bench-timing-type
> > -rwxr-xr-x 1 zimmerma caramba 35760 Jan 16 07:48 /tmp/glibc/build/benchtests/bench-timing-type
> > 
> > $ file /tmp/glibc/build/benchtests/bench-timing-type
> > /tmp/glibc/build/benchtests/bench-timing-type: ELF 64-bit LSB shared object,
> > x86-64, version 1 (SYSV), dynamically linked, interpreter /tmp/lib/ld-linux-x86-64.so.2,
>                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > BuildID[sha1]=6eaee68beda7ba9d3a4e7c329d427b5c0676483d, for GNU/Linux 3.2.0, with debug_info, not stripped
> > 
> > however it does not want to run:
> > 
> > $ /tmp/glibc/build/benchtests/bench-timing-type
> > -bash: /tmp/glibc/build/benchtests/bench-timing-type: No such file or directory
> 
> that executable seems to be built with
> 
>  -Wl,-dynamic-linker=/tmp/lib/ld-linux-x86-64.so.2
> 
> which does not exist, you can quickly fix it now
> by making that a symlink to wherever the dynamic
> linker is (and set up runtime library paths where
> libc.so.6 etc is)
> 
> but i think ideally your host toolchain should
> not produce executables that cannot run.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-16 10:34       ` paul zimmermann
@ 2020-01-16 16:31         ` Joseph Myers
  2020-01-18 12:18           ` paul zimmermann
  0 siblings, 1 reply; 9+ messages in thread
From: Joseph Myers @ 2020-01-16 16:31 UTC (permalink / raw)
  To: paul zimmermann; +Cc: Szabolcs Nagy, carlos, nd, libc-alpha

On Thu, 16 Jan 2020, paul zimmermann wrote:

> thank you Szabolcs, this solved the problem.
> 
> However, I believe the issue is on the glibc side. Indeed, the
> bench-timing-type is linked with /tmp/lib/ld-linux-x86-64.so.2
> by the glibc Makefile, and that file doesn't exist if "make install"
> was not done (I configured with ./configure --prefix=/tmp).

The normal configuration people generally test with has --prefix=/usr.

However, what this indicates to me is that the call of $(timing-type) 
needs to use $(test-via-rtld-prefix).  Does this (untested) patch help in 
your configuration using --prefix=/tmp?


Run bench-timing-type with newly built libc.

benchtests/timing-type is built with the newly built libc, so should
be run with it like actual tests and benchmarks.

diff --git a/benchtests/Makefile b/benchtests/Makefile
index 99c3fae9bf..71b9565fed 100644
--- a/benchtests/Makefile
+++ b/benchtests/Makefile
@@ -217,7 +217,10 @@ bench-malloc: $(binaries-bench-malloc)
 # capable language or tool.
 bench-func: $(binaries-bench)
 	if [ -n '$^' ] ; then \
-	{ timing_type=$$($(timing-type)); \
+	{ timing_type=$$($(test-wrapper-env) \
+			 $(run-program-env) \
+			 $(test-via-rtld-prefix) \
+			 $(timing-type)); \
 	  echo "{\"timing_type\": \"$${timing_type}\","; \
 	  echo " \"functions\": {"; \
 	  for run in $^; do \

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-16 16:31         ` Joseph Myers
@ 2020-01-18 12:18           ` paul zimmermann
  2020-01-20 11:23             ` Joseph Myers
  0 siblings, 1 reply; 9+ messages in thread
From: paul zimmermann @ 2020-01-18 12:18 UTC (permalink / raw)
  To: Joseph Myers; +Cc: Szabolcs.Nagy, carlos, nd, libc-alpha

       Dear Joseph,

> Date: Thu, 16 Jan 2020 16:31:05 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> 
> On Thu, 16 Jan 2020, paul zimmermann wrote:
> 
> > thank you Szabolcs, this solved the problem.
> > 
> > However, I believe the issue is on the glibc side. Indeed, the
> > bench-timing-type is linked with /tmp/lib/ld-linux-x86-64.so.2
> > by the glibc Makefile, and that file doesn't exist if "make install"
> > was not done (I configured with ./configure --prefix=/tmp).
> 
> The normal configuration people generally test with has --prefix=/usr.
> 
> However, what this indicates to me is that the call of $(timing-type) 
> needs to use $(test-via-rtld-prefix).  Does this (untested) patch help in 
> your configuration using --prefix=/tmp?
> 
> 
> Run bench-timing-type with newly built libc.
> 
> benchtests/timing-type is built with the newly built libc, so should
> be run with it like actual tests and benchmarks.
> 
> diff --git a/benchtests/Makefile b/benchtests/Makefile
> index 99c3fae9bf..71b9565fed 100644
> --- a/benchtests/Makefile
> +++ b/benchtests/Makefile
> @@ -217,7 +217,10 @@ bench-malloc: $(binaries-bench-malloc)
>  # capable language or tool.
>  bench-func: $(binaries-bench)
>  	if [ -n '$^' ] ; then \
> -	{ timing_type=$$($(timing-type)); \
> +	{ timing_type=$$($(test-wrapper-env) \
> +			 $(run-program-env) \
> +			 $(test-via-rtld-prefix) \
> +			 $(timing-type)); \
>  	  echo "{\"timing_type\": \"$${timing_type}\","; \
>  	  echo " \"functions\": {"; \
>  	  for run in $^; do \

yes this patch solves the issue.

Paul

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-18 12:18           ` paul zimmermann
@ 2020-01-20 11:23             ` Joseph Myers
  2020-01-20 11:26               ` Siddhesh Poyarekar
  0 siblings, 1 reply; 9+ messages in thread
From: Joseph Myers @ 2020-01-20 11:23 UTC (permalink / raw)
  To: paul zimmermann; +Cc: Szabolcs.Nagy, carlos, nd, libc-alpha, siddhesh

On Sat, 18 Jan 2020, paul zimmermann wrote:

> yes this patch solves the issue.

Siddhesh, is this patch 
<https://sourceware.org/ml/libc-alpha/2020-01/msg00346.html> OK for the 
current development stage?

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: error when running "make bench"
  2020-01-20 11:23             ` Joseph Myers
@ 2020-01-20 11:26               ` Siddhesh Poyarekar
  0 siblings, 0 replies; 9+ messages in thread
From: Siddhesh Poyarekar @ 2020-01-20 11:26 UTC (permalink / raw)
  To: Joseph Myers, paul zimmermann; +Cc: Szabolcs.Nagy, carlos, nd, libc-alpha



On 20/01/20 4:53 pm, Joseph Myers wrote:
> On Sat, 18 Jan 2020, paul zimmermann wrote:
> 
>> yes this patch solves the issue.
> 
> Siddhesh, is this patch 
> <https://sourceware.org/ml/libc-alpha/2020-01/msg00346.html> OK for the 
> current development stage?
> 

Yes, this patch is OK for master.

Thanks,
Siddhesh

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-01-20 11:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-15 16:55 error when running "make bench" paul zimmermann
2020-01-15 17:33 ` Carlos O'Donell
2020-01-16  6:57   ` paul zimmermann
2020-01-16  9:27     ` Szabolcs Nagy
2020-01-16 10:34       ` paul zimmermann
2020-01-16 16:31         ` Joseph Myers
2020-01-18 12:18           ` paul zimmermann
2020-01-20 11:23             ` Joseph Myers
2020-01-20 11:26               ` Siddhesh Poyarekar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).