[ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

[-- Attachment #1.1: Type: text/plain, Size: 2599 bytes --]

I'm currently using ptxdist 2015.10.0 and I've selected valgrind as a
built-in option in the 'Debug Tools' using menuconfig.  Valgrind is then
installed in my image at /usr/bin/valgrind.  However, it is currently
not usable since the available glibc is too optimized, resulting in the
following message.

> 

>             valgrind:  Fatal error at startup: a function redirection

>             valgrind:  which is mandatory for this platform-tool
combination

>             valgrind:  cannot be set up.  Details of the redirection
are:

>             valgrind:  

>             valgrind:  A must-be-redirected function

>             valgrind:  whose name matches the pattern:      strcmp

>             valgrind:  in an object with soname matching:
ld-linux-armhf.so.3

>             valgrind:  was not found whilst processing

>             valgrind:  symbols from the object with soname:
ld-linux-armhf.so.3

>             valgrind:  

>             valgrind:  Possible fixes: (1, short term): install
glibc's debuginfo

>             valgrind:  package on this machine.  (2, longer term): ask
the packagers

>             valgrind:  for your Linux distribution to please in future
ship a non-

>             valgrind:  stripped ld.so (or whatever the dynamic linker
.so is called)

>             valgrind:  that exports the above-named function using the
standard

>             valgrind:  calling conventions for this platform.  The
package you need

>             valgrind:  to install for fix (1) is called

>             valgrind:  

>             valgrind:    On Debian, Ubuntu:                 libc6-dbg

>             valgrind:    On SuSE, openSuSE, Fedora, RHEL:
glibc-debuginfo

>             valgrind:  

>             valgrind:  Cannot continue -- exiting now.  Sorry.

 

I've found a couple of references to the optimization being the culprit,
such as https://sourceforge.net/p/valgrind/mailman/message/30887009/

> 

>             ...

>             Very probably these are due to calls on strlen() or
memcpy() which have been

>             expanded inline because of aggressive optimization
("#include <string.h>"

>             compiled with -O2 or -O3.)

>             ...

 

 

Is there a method of configuring glibc to build un-optimized ( below
-O2) for use with the valgrind tool?

Can the valgrind selection automatically trigger this un-optimized
build?

Or, if there are other suggestions for addressing this issue, I'd like
to hear them.

 

Thanks,

- Jason Crim


[-- Attachment #1.2: Type: text/html, Size: 7404 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Michael Olbrich]

Hi,

On Thu, Mar 22, 2018 at 12:38:21PM -0500, Crim, Jason wrote:
> I'm currently using ptxdist 2015.10.0 and I've selected valgrind as a
> built-in option in the 'Debug Tools' using menuconfig.  Valgrind is then
> installed in my image at /usr/bin/valgrind.  However, it is currently
> not usable since the available glibc is too optimized, resulting in the
> following message.
[...]
> Is there a method of configuring glibc to build un-optimized ( below
> -O2) for use with the valgrind tool?
> 
> Can the valgrind selection automatically trigger this un-optimized
> build?
> 
> Or, if there are other suggestions for addressing this issue, I'd like
> to hear them.

The problem is not the optimization, but the missing debug symbols. With
this PTXdist Version you need to use the nfsroot. The debug symbols are
available there.
Or you can update to the latest PTXdist and Toolchain version. Then you can
enable debug packages that can be installed on the live system.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

Thanks,
   I'd tried moving over the root-debug versions of the referenced files, and was still hitting the error.  That's when I'd found the post referencing the optimization levels.  I'll take a look at getting the nfs-root running when I've got some time.

Thanks for the information and advice,
 - Jason

-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Monday, March 26, 2018 2:30 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi,

On Thu, Mar 22, 2018 at 12:38:21PM -0500, Crim, Jason wrote:
> I'm currently using ptxdist 2015.10.0 and I've selected valgrind as a 
> built-in option in the 'Debug Tools' using menuconfig.  Valgrind is 
> then installed in my image at /usr/bin/valgrind.  However, it is 
> currently not usable since the available glibc is too optimized, 
> resulting in the following message.
[...]
> Is there a method of configuring glibc to build un-optimized ( below
> -O2) for use with the valgrind tool?
> 
> Can the valgrind selection automatically trigger this un-optimized 
> build?
> 
> Or, if there are other suggestions for addressing this issue, I'd like 
> to hear them.

The problem is not the optimization, but the missing debug symbols. With this PTXdist Version you need to use the nfsroot. The debug symbols are available there.
Or you can update to the latest PTXdist and Toolchain version. Then you can enable debug packages that can be installed on the live system.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Michael Olbrich]

Hi,

On Mon, Mar 26, 2018 at 07:03:21AM -0500, Crim, Jason wrote:
> I'd tried moving over the root-debug versions of the referenced files, and
> was still hitting the error.  That's when I'd found the post referencing
> the optimization levels.  I'll take a look at getting the nfs-root running
> when I've got some time.

Hmm, strage, The only problems I've seen are with stripped binaries. Which
toolchain are you using?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

Michael,

It looks like the toolchain is configured as OSELAS.Toolchain-2014.12.  I've recently been added to a team which had this existing ptxdist setup, so I've been trying to learn my way around ptxdist while trying to get valgrind enabled to test an issue.

The initial run of valgrind results in the message shown in my first message:
>
>	==5596== Memcheck, a memory error detector
>	==5596== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>	==5596== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
>	==5596== Command: /usr/bin/device
>	==5596== 
>
>	valgrind:  Fatal error at startup: a function redirection
>	valgrind:  which is mandatory for this platform-tool combination
>	valgrind:  cannot be set up.  Details of the redirection are:
>	valgrind:  
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      strcmp
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	valgrind:  
>	valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>	valgrind:  package on this machine.  (2, longer term): ask the packagers
>	valgrind:  for your Linux distribution to please in future ship a non-
>	valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>	valgrind:  that exports the above-named function using the standard
>	valgrind:  calling conventions for this platform.  The package you need
>	valgrind:  to install for fix (1) is called
>	valgrind:  
>	valgrind:    On Debian, Ubuntu:                 libc6-dbg
>	valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
>	valgrind:  
>	valgrind:  Cannot continue -- exiting now.  Sorry.


Since ld-linux-armhf.so.3 is a symlink to ld-2.20.so, I copied ld-2.20.so from the root-debug/lib location and re-ran valgrind.  The referenced function changed, but the file it expected it in did not (for brevity, I've only retained the function and file lines).
>
>	...
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      memcpy
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	...

The fact that the reference was expected in the same file, along with additional searching, led me to think that the optimization was the problem.


Thanks,
 - Jason



-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Tuesday, March 27, 2018 3:34 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi,

On Mon, Mar 26, 2018 at 07:03:21AM -0500, Crim, Jason wrote:
> I'd tried moving over the root-debug versions of the referenced files, 
> and was still hitting the error.  That's when I'd found the post 
> referencing the optimization levels.  I'll take a look at getting the 
> nfs-root running when I've got some time.

Hmm, strage, The only problems I've seen are with stripped binaries. Which toolchain are you using?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Andrej.Gantvorg]

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

Hi Jason,


we had experienced a similar problem with the OSELAS 2012.12.1 toolchain. 
In our case the problem was the missing .size directive in assembler reimplementations of strlen and memcpy from the linaro cortex-strings patch for glibc.

Does your "readelf -s /path/to/your/libc.so.6" output look like this?

...
828: 00019491 0 FUNC LOCAL DEFAULT 10 memcpy
...
949: 00018690 164 FUNC LOCAL DEFAULT 10 strcmp
...
996: 000189d1 0 FUNC LOCAL DEFAULT 10 strlen
...

Note the zeroes  in the 3rd column. If so, you may have the same problem.

You may find our workaround in the attachment. The patch has to be applied after the Linaro NEON patch. No idea why strcmp also had to be touched though.


Andrej

-----Ursprüngliche Nachricht-----
Von: ptxdist [mailto:ptxdist-bounces@pengutronix.de] Im Auftrag von Crim, Jason
Gesendet: Dienstag, 27. März 2018 1:54
An: ptxdist@pengutronix.de
Betreff: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Michael,

It looks like the toolchain is configured as OSELAS.Toolchain-2014.12.  I've recently been added to a team which had this existing ptxdist setup, so I've been trying to learn my way around ptxdist while trying to get valgrind enabled to test an issue.

The initial run of valgrind results in the message shown in my first message:
>
>	==5596== Memcheck, a memory error detector
>	==5596== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>	==5596== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
>	==5596== Command: /usr/bin/device
>	==5596==
>
>	valgrind:  Fatal error at startup: a function redirection
>	valgrind:  which is mandatory for this platform-tool combination
>	valgrind:  cannot be set up.  Details of the redirection are:
>	valgrind:  
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      strcmp
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	valgrind:  
>	valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>	valgrind:  package on this machine.  (2, longer term): ask the packagers
>	valgrind:  for your Linux distribution to please in future ship a non-
>	valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>	valgrind:  that exports the above-named function using the standard
>	valgrind:  calling conventions for this platform.  The package you need
>	valgrind:  to install for fix (1) is called
>	valgrind:  
>	valgrind:    On Debian, Ubuntu:                 libc6-dbg
>	valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
>	valgrind:  
>	valgrind:  Cannot continue -- exiting now.  Sorry.


Since ld-linux-armhf.so.3 is a symlink to ld-2.20.so, I copied ld-2.20.so from the root-debug/lib location and re-ran valgrind.  The referenced function changed, but the file it expected it in did not (for brevity, I've only retained the function and file lines).
>
>	...
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      memcpy
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	...

The fact that the reference was expected in the same file, along with additional searching, led me to think that the optimization was the problem.


Thanks,
 - Jason



-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Tuesday, March 27, 2018 3:34 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi,

On Mon, Mar 26, 2018 at 07:03:21AM -0500, Crim, Jason wrote:
> I'd tried moving over the root-debug versions of the referenced files, 
> and was still hitting the error.  That's when I'd found the post 
> referencing the optimization levels.  I'll take a look at getting the 
> nfs-root running when I've got some time.

Hmm, strage, The only problems I've seen are with stripped binaries. Which toolchain are you using?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

[-- Attachment #2: 9999-add-size-directive-for-memcpy-strlen-strcmp.patch --]
[-- Type: application/octet-stream, Size: 1876 bytes --]

Index: glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/memcpy.S
===================================================================
--- glibc-2.16.0.orig/cortex-strings/sysdeps/arm/armv7/memcpy.S	2016-10-21 13:10:33.396430399 +0000
+++ glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/memcpy.S	2016-10-21 13:12:43.384611374 +0000
@@ -158,5 +158,6 @@
 	cmp	r2,#32
 	blt	10b
 	b	4b
+	.size	memcpy, . - memcpy
 
 libc_hidden_builtin_def (memcpy)
Index: glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/strcmp.c
===================================================================
--- glibc-2.16.0.orig/cortex-strings/sysdeps/arm/armv7/strcmp.c	2016-10-21 13:10:33.380430399 +0000
+++ glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/strcmp.c	2016-10-21 13:15:00.801281270 +0000
@@ -137,7 +137,7 @@
 #ifndef __thumb2__
       "ldr	r4, [sp], #4\n\t"
 #endif
-      "BX LR"
+      "BX LR\n\t"
 #elif (defined (__thumb__) && !defined (__thumb2__))
   "1:\n\t"
       "ldrb	r2, [r0]\n\t"
@@ -150,7 +150,7 @@
       "beq	1b\n\t"
   "2:\n\t"
       "sub	r0, r2, r3\n\t"
-      "bx	lr"
+      "bx	lr\n\t"
 #else
  "3:\n\t"
       "ldrb	r2, [r0], #1\n\t"
@@ -160,8 +160,9 @@
       "cmpcs	r2, r3\n\t"
       "beq	3b\n\t"
       "sub	r0, r2, r3\n\t"
-      "BX LR"
+      "BX LR\n\t"
 #endif
+      ".size	strcmp, . - strcmp"
       );
 }
 
Index: glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/strlen.S
===================================================================
--- glibc-2.16.0.orig/cortex-strings/sysdeps/arm/armv7/strlen.S	2016-10-21 13:10:33.392430399 +0000
+++ glibc-2.16.0/cortex-strings/sysdeps/arm/armv7/strlen.S	2016-10-21 13:13:29.495653997 +0000
@@ -80,6 +80,7 @@
 	sel	r3, r2, r6	@ bytes are 00 for none-00 bytes, or ff for 00 bytes - NOTE INVERSION
 	cmp	r3, #0
 	beq	2b
+	.size	strlen, . - strlen
 
 strlenendtmp:
 	@ One (or more) of the bytes we loaded was 0 - but which one?

[-- Attachment #3: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

Andrej,

Thanks for your information.  My setup includes glibc 2.20 rather than the 2.16 referenced in your patch file, so I don't think it'll work directly (the source of 2.20 and 2.16 look pretty different - actually, I'm not even seeing the files referenced in the 2.16 source I pulled from the glibc archive today), but perhaps it'll help me find the answers I need.

My results from readelf on libc.so.6 look a bit different:
>		 14499: 00058f21     0 FUNC    GLOBAL DEFAULT   11 memcpy
>		 12773: 00056f11   740 FUNC    GLOBAL DEFAULT   11 strcmp
>		 14536: 00057701   220 FUNC    GLOBAL DEFAULT   11 strlen

there are no "FUNC	LOCAL	DEFAULT" for the base functions - though memcpy does have a size of 0 here.

My ld-2.20.so (which is the file valgrind referenced) yeilds similar results to yours:
>		   916: 00012921     0 FUNC    LOCAL  DEFAULT   10 memcpy
>		  1033: 00011b31   740 FUNC    LOCAL  DEFAULT   10 strcmp
>		  1083: 00012041   220 FUNC    LOCAL  DEFAULT   10 strlen
		  
with the exception of strcmp and strlen.  Which makes sense given the valgrind output in my last message.  Replacing ld-2.20.so moved the error from strcmp to memcpy.

I'm actually seeing similar entries ('0 FUNC    LOCAL  DEFAULT') for memcpy, memchr, index, memset, and strchr in ld-2.20.so.

 - Jason


-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Andrej.Gantvorg@wago.com
Sent: Wednesday, March 28, 2018 6:02 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi Jason,


we had experienced a similar problem with the OSELAS 2012.12.1 toolchain. 
In our case the problem was the missing .size directive in assembler reimplementations of strlen and memcpy from the linaro cortex-strings patch for glibc.

Does your "readelf -s /path/to/your/libc.so.6" output look like this?

...
828: 00019491 0 FUNC LOCAL DEFAULT 10 memcpy ...
949: 00018690 164 FUNC LOCAL DEFAULT 10 strcmp ...
996: 000189d1 0 FUNC LOCAL DEFAULT 10 strlen ...

Note the zeroes  in the 3rd column. If so, you may have the same problem.

You may find our workaround in the attachment. The patch has to be applied after the Linaro NEON patch. No idea why strcmp also had to be touched though.


Andrej

-----Ursprüngliche Nachricht-----
Von: ptxdist [mailto:ptxdist-bounces@pengutronix.de] Im Auftrag von Crim, Jason
Gesendet: Dienstag, 27. März 2018 1:54
An: ptxdist@pengutronix.de
Betreff: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Michael,

It looks like the toolchain is configured as OSELAS.Toolchain-2014.12.  I've recently been added to a team which had this existing ptxdist setup, so I've been trying to learn my way around ptxdist while trying to get valgrind enabled to test an issue.

The initial run of valgrind results in the message shown in my first message:
>
>	==5596== Memcheck, a memory error detector
>	==5596== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>	==5596== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
>	==5596== Command: /usr/bin/device
>	==5596==
>
>	valgrind:  Fatal error at startup: a function redirection
>	valgrind:  which is mandatory for this platform-tool combination
>	valgrind:  cannot be set up.  Details of the redirection are:
>	valgrind:  
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      strcmp
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	valgrind:  
>	valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
>	valgrind:  package on this machine.  (2, longer term): ask the packagers
>	valgrind:  for your Linux distribution to please in future ship a non-
>	valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
>	valgrind:  that exports the above-named function using the standard
>	valgrind:  calling conventions for this platform.  The package you need
>	valgrind:  to install for fix (1) is called
>	valgrind:  
>	valgrind:    On Debian, Ubuntu:                 libc6-dbg
>	valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
>	valgrind:  
>	valgrind:  Cannot continue -- exiting now.  Sorry.


Since ld-linux-armhf.so.3 is a symlink to ld-2.20.so, I copied ld-2.20.so from the root-debug/lib location and re-ran valgrind.  The referenced function changed, but the file it expected it in did not (for brevity, I've only retained the function and file lines).
>
>	...
>	valgrind:  A must-be-redirected function
>	valgrind:  whose name matches the pattern:      memcpy
>	valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
>	valgrind:  was not found whilst processing
>	valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
>	...

The fact that the reference was expected in the same file, along with additional searching, led me to think that the optimization was the problem.


Thanks,
 - Jason



-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Tuesday, March 27, 2018 3:34 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi,

On Mon, Mar 26, 2018 at 07:03:21AM -0500, Crim, Jason wrote:
> I'd tried moving over the root-debug versions of the referenced files, 
> and was still hitting the error.  That's when I'd found the post 
> referencing the optimization levels.  I'll take a look at getting the 
> nfs-root running when I've got some time.

Hmm, strage, The only problems I've seen are with stripped binaries. Which toolchain are you using?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Michael Olbrich]

On Wed, Mar 28, 2018 at 10:43:14AM -0500, Crim, Jason wrote:
> Thanks for your information.  My setup includes glibc 2.20 rather than the
> 2.16 referenced in your patch file, so I don't think it'll work directly (the
> source of 2.20 and 2.16 look pretty different - actually, I'm not even seeing
> the files referenced in the 2.16 source I pulled from the glibc archive
> today), but perhaps it'll help me find the answers I need.
> 
> My results from readelf on libc.so.6 look a bit different:
> >		 14499: 00058f21     0 FUNC    GLOBAL DEFAULT   11 memcpy
> >		 12773: 00056f11   740 FUNC    GLOBAL DEFAULT   11 strcmp
> >		 14536: 00057701   220 FUNC    GLOBAL DEFAULT   11 strlen
> 
> there are no "FUNC	LOCAL	DEFAULT" for the base functions - though memcpy does have a size of 0 here.
> 
> My ld-2.20.so (which is the file valgrind referenced) yeilds similar results to yours:
> >		   916: 00012921     0 FUNC    LOCAL  DEFAULT   10 memcpy
> >		  1033: 00011b31   740 FUNC    LOCAL  DEFAULT   10 strcmp
> >		  1083: 00012041   220 FUNC    LOCAL  DEFAULT   10 strlen
> 		  
> with the exception of strcmp and strlen.  Which makes sense given the
> valgrind output in my last message.  Replacing ld-2.20.so moved the error
> from strcmp to memcpy.
> 
> I'm actually seeing similar entries ('0 FUNC    LOCAL  DEFAULT') for memcpy,
> memchr, index, memset, and strchr in ld-2.20.so.

If you use the cortexa8 toolchain, the you can avoid the problem mentioned
by Andrej by switching to the v7a toolchain. It optimizes a bit differently
but should work for you.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

Michael, thank you for your suggestion.

I've got my toolchain switched to the arm-v7a-linux-gnueabihf (from the arm-cortexa8-linux-gnueabihf), and valgrind is now working.  It complains about _armv7_tick being an unrecognized instruction, but my program does continue to run (in defiance of valgrind's warning message).

Long term, what are the trade-offs for using the v7a vs. the cortexa8 toolchains in production?  I do not know the history of the decision in my organization, but the cortex toolchain was in place before my arrival.  I'm trying to decide whether to keep the change local on my dev/debug system, or suggest a migration.

Thanks again.
 - Jason

-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Thursday, March 29, 2018 5:21 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

On Wed, Mar 28, 2018 at 10:43:14AM -0500, Crim, Jason wrote:
> Thanks for your information.  My setup includes glibc 2.20 rather than 
> the
> 2.16 referenced in your patch file, so I don't think it'll work 
> directly (the source of 2.20 and 2.16 look pretty different - 
> actually, I'm not even seeing the files referenced in the 2.16 source 
> I pulled from the glibc archive today), but perhaps it'll help me find the answers I need.
> 
> My results from readelf on libc.so.6 look a bit different:
> >		 14499: 00058f21     0 FUNC    GLOBAL DEFAULT   11 memcpy
> >		 12773: 00056f11   740 FUNC    GLOBAL DEFAULT   11 strcmp
> >		 14536: 00057701   220 FUNC    GLOBAL DEFAULT   11 strlen
> 
> there are no "FUNC	LOCAL	DEFAULT" for the base functions - though memcpy does have a size of 0 here.
> 
> My ld-2.20.so (which is the file valgrind referenced) yeilds similar results to yours:
> >		   916: 00012921     0 FUNC    LOCAL  DEFAULT   10 memcpy
> >		  1033: 00011b31   740 FUNC    LOCAL  DEFAULT   10 strcmp
> >		  1083: 00012041   220 FUNC    LOCAL  DEFAULT   10 strlen
> 		  
> with the exception of strcmp and strlen.  Which makes sense given the 
> valgrind output in my last message.  Replacing ld-2.20.so moved the 
> error from strcmp to memcpy.
> 
> I'm actually seeing similar entries ('0 FUNC    LOCAL  DEFAULT') for memcpy,
> memchr, index, memset, and strchr in ld-2.20.so.

If you use the cortexa8 toolchain, the you can avoid the problem mentioned by Andrej by switching to the v7a toolchain. It optimizes a bit differently but should work for you.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Michael Olbrich]

Hi,

On Thu, Apr 05, 2018 at 02:41:38PM -0500, Crim, Jason wrote:
> I've got my toolchain switched to the arm-v7a-linux-gnueabihf (from the
> arm-cortexa8-linux-gnueabihf), and valgrind is now working.  It complains
> about _armv7_tick being an unrecognized instruction, but my program does
> continue to run (in defiance of valgrind's warning message).
> 
> Long term, what are the trade-offs for using the v7a vs. the cortexa8
> toolchains in production?  I do not know the history of the decision in my
> organization, but the cortex toolchain was in place before my arrival.  I'm
> trying to decide whether to keep the change local on my dev/debug system, or
> suggest a migration.

I recommend using v7a. It uses the same settings as most armhf
distributions, so this has better test coverage. I actually dropped the
cortexa8 toolchain from the latest OSELAS.Toolchain release.
It may be a bit slower depending on your hardware. What's your cpu anyways?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Crim, Jason]

I'd noticed that the cortexa8 toolchain was not available when I was starting to set up a new test build-environment with the latest versions.  We're using the TI AM3352.

Thanks,
 - Jason

-----Original Message-----
From: ptxdist [mailto:ptxdist-bounces@pengutronix.de] On Behalf Of Michael Olbrich
Sent: Monday, April 09, 2018 4:41 AM
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

Hi,

On Thu, Apr 05, 2018 at 02:41:38PM -0500, Crim, Jason wrote:
> I've got my toolchain switched to the arm-v7a-linux-gnueabihf (from 
> the arm-cortexa8-linux-gnueabihf), and valgrind is now working.  It 
> complains about _armv7_tick being an unrecognized instruction, but my 
> program does continue to run (in defiance of valgrind's warning message).
> 
> Long term, what are the trade-offs for using the v7a vs. the cortexa8 
> toolchains in production?  I do not know the history of the decision 
> in my organization, but the cortex toolchain was in place before my 
> arrival.  I'm trying to decide whether to keep the change local on my 
> dev/debug system, or suggest a migration.

I recommend using v7a. It uses the same settings as most armhf distributions, so this has better test coverage. I actually dropped the
cortexa8 toolchain from the latest OSELAS.Toolchain release.
It may be a bit slower depending on your hardware. What's your cpu anyways?

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] Including valgrind in the configuration doesn't trigger an un-optimized build of glibc.

[Michael Olbrich]

On Mon, Apr 09, 2018 at 07:13:00AM -0500, Crim, Jason wrote:
> I'd noticed that the cortexa8 toolchain was not available when I was starting
> to set up a new test build-environment with the latest versions.  We're using
> the TI AM3352.

The v7a toolchain works just fine with this CPU.  You can add
'-mcpu=cortex-a8 -mfpu=neon' to TARGET_EXTRA_CFLAGS/CXXFLAGS. This way,
the rest of the BSP will be compiled with the same optimizations as before.
But you probably won't notice the difference.


Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de