Bug 339605 - vgpreload_helgrind-arm-linux.so is not linked to libc.so and can't find sched_yield, pthread_self and so on
Summary: vgpreload_helgrind-arm-linux.so is not linked to libc.so and can't find sched...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: valgrind
Classification: Developer tools
Component: helgrind (show other bugs)
Version: unspecified
Platform: Android Android 4.x
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-02 13:07 UTC by Vitaly "_Vi" Shukela
Modified: 2023-01-11 17:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaly "_Vi" Shukela 2014-10-02 13:07:06 UTC
If I manually add "-lc" when building the library then it works.
Comment 1 Vitaly "_Vi" Shukela 2014-10-02 13:10:30 UTC
Version is 3.10.0
Comment 2 Philippe Waroquiers 2014-10-02 19:32:20 UTC
(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  ?
Comment 3 Vitaly "_Vi" Shukela 2014-10-03 13:31:17 UTC
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
Comment 4 Vitaly "_Vi" Shukela 2014-10-03 15:36:53 UTC
There may be a similar problem with vgpreload_drd-arm-linux.so .
Comment 5 Paul Floyd 2023-01-11 09:45:13 UTC
Is your application linked with libpthread and does it run correctly on its own?
Comment 6 Vitaly "_Vi" Shukela 2023-01-11 10:09:20 UTC
> 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.
Comment 7 Paul Floyd 2023-01-11 10:30:27 UTC
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?
Comment 8 Vitaly "_Vi" Shukela 2023-01-11 11:23:50 UTC
If there will be more similar problems, I'll probably open another issue.