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

[<Andrej.Gantvorg@wago.com>]

[-- 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