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

["Crim, Jason" <jason.crim@thyssenkrupp.com>]

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