If I manually add "-lc" when building the library then it works.
Version is 3.10.0
(In reply to Vitaly "_Vi" Shukela from comment #0) > If I manually add "-lc" when building the library then it works. It looks normal to me that vgpreload_helgrind-arm-linux.so has some unresolved references. These will be resolved at runtime. I do not have a working android setup, but on a x86 linux: nm vgpreload_helgrind-x86-linux.so | grep yield gives U sched_yield Can you copy/paste the last relevant lines of the build failure, showing which build command fails, and the relevant 'link' error messages ?
It's not a build failure, it's runtime failure. `valgrind --tool=memcheck` or `valgrind --tool=callgrind` works, but `valgrind --tool=helgrind` fails to start complaining about unresolved "sched_yield". If I declare empty "sched_yield" in the program being debugged then it complains about "pthread_self" (you can see the list of undefined symbols with `readelf -d` - sched_yield is just the first). If I spy the command line used to link vgpreload_helgrind-arm-linux.so and manually run the command line with additional "-lc" command then the resulting vgpreload_helgrind-arm-linux.so gains dependency on "libc.so" (it has not dependencies at all by default) and helgrind launches successfully. Here is example of running helgrind with unfixed library ("myapp" has dummy "sched_yield"): adb shell "/data/local/tmp/valgrind/bin/valgrind --tool=helgrind /data/local/tmp/myapp" ==9507== Helgrind, a thread error detector ==9507== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al. ==9507== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==9507== Command: /data/local/tmp/myapp ==9507== CANNOT LINK EXECUTABLE: could not load library "/data/local/tmp/valgrind/lib/valgrind/vgpreload_helgrind-arm-linux.so" needed by "/data/local/tmp/myapp"; caused by cannot locate symbol "pthread_self" referenced by "vgpreload_helgrind-arm-linux.so"... ==9507== ==9507== For counts of detected and suppressed errors, rerun with: -v ==9507== Use --history-level=approx or =none to gain increased speed, at ==9507== the cost of reduced accuracy of conflicting-access information ==9507== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) There is pre-build Anroid version (with unfixed library) here: http://vi-server.org/pub/valgrind-3.10.0-for-unrooted-android.tar.gz
There may be a similar problem with vgpreload_drd-arm-linux.so .
Is your application linked with libpthread and does it run correctly on its own?
> Is your application linked with libpthread and does it run correctly on its own? I don't remember which application it was, but probably it worked correctly (apart from bugs to be debugged using valgrind), and according to my previous comment it also worked in Valgrind (but other tool). It was 8 years ago, so many things both in Android, Valgrind and toolchains for building apps could have changed.
Indeed. I've been tryiing to slowly clear out some old bugzilla items. Normally the way that valgrind works is that valgrind is a small stub exe that just execs the tool (I'll use helgrind as an example). helgrind doesn't link with libc and doesn't even have a main(). It just has an assembler _start. It bootstraps itself out of the way of the memory that the guest gets loaded into. Then to start the guest it sets LD_PRELOAD for the core and helgrind preload dynamic libs, loads ld.so and the guest exe and starts running the ld.so code in the Valgrind VM. Normally the undefined symbols in the preload helgrind lib will be satisfied by the guest exe, either directly or indirectly. If this is no longer an issue, can I close it?
If there will be more similar problems, I'll probably open another issue.