Issue metadata
Sign in to add a comment
|
valgrind requires unstripped dynamic linker/loader |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: When using the toolchain from https://storage.googleapis.com/chromiumos-sdk/2018/04/armv7a-cros-linux-gnueabihf-2018.04.12.144229.tar.xz to cross compile a Linux based OS for a target ARM device, run valgrind on a program. valgrind then has a fatal error at startup as the dynamic linker/loader (ld-linux-armhf.so.3) is stripped. What is the expected behavior? valgrind should be usable with the dynamic linker/loader from the toolchain What went wrong? ==821== Memcheck, a memory error detector ==821== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==821== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==821== Command: connect_test ==821== 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: Note that if you are debugging a 32 bit process on a valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo valgrind: package (e.g. libc6-dbg:i386). valgrind: valgrind: Cannot continue -- exiting now. Sorry. Did this work before? No Chrome version: 67.0.3396.99 Channel: stable OS Version: Flash Version: Apologies that this bug is lodged under the Development Tools - there doesn't seem to be a way to raise one directly against Tools>ChromeOS-Toolchain
,
Jul 18
,
Jul 31
Just confirming here that the tarballs with the debug files included for glibc are usable in place of an unstripped linker/loader, but not sure if these are publicly available.
,
Jul 31
I am sure that the files themselves are public readable since opensource builds also fetch these files. But maybe directory has some restrictions on listing the files. vapier@ should know more about the storage permissions.
,
Jul 31
what bucket/file are you talking about exactly ? everything under gs://chromiumos-sdk/ is world readable by design.
,
Jul 31
This is for files in gs://chromeos-prebuilt/host/amd64/amd64-host/chroot-*/packages
,
Jul 31
all those files are world readable by design. the bucket doesn't have default ACLs so you can browse things with `ls`, but that's also to be expected. you can see in the chromiumos-sdk UploadPrebuilts stage how we use the "public-read" ACL when posting all those archives.
,
Jul 31
powelljeremy@ What error do you get with this? $ gsutil ls gs://chromeos-prebuilt/host/amd64/amd64-host/chroot-2018.07.10.123215/packages/cross-armv7a-cros-linux-gnueabihf/*
,
Jul 31
Yeah, looks like the artifacts themselves are world-readable, which is fine for our purposes. However, I couldn't find the artifact I needed without logging in to be able to browse. @manojgupta $ gsutil ls gs://chromeos-prebuilt/host/amd64/amd64-host/chroot-2018.07.10.123215/packages/cross-armv7a-cros-linux-gnueabihf/* ServiceException: 401 Anonymous caller does not have storage.objects.list access to chromeos-prebuilt.
,
Aug 1
if using the .debug files we already publish is sufficient, you should use that. i don't see us disabling stripping on files in release just to make valgrind pass.
,
Aug 1
Agreed - I just wasn't initially aware that those files existed, since I couldn't browse them publicly. Now that I have the corresponding URLs I need, and the artifacts themselves are public, I'm happy with the current state of things. Thanks very much for your help!
,
Aug 2
Thanks, Closing this! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manojgupta@chromium.org
, Jul 17Labels: -OS-Linux -Via-Wizard-DeveloperTools OS-Chrome