Re: [PATCH v2 2/2] Make ftrace tests work with remote targets

[Yao Qi <qiyaoltc@gmail.com>]

Simon Marchi <simon.marchi@ericsson.com> writes:

> The executable and the library are then uploaded side-by-side on the
> remote system.  To allow the dynamic linker to find the shared library,
> we have to add the special RPATH value $ORIGIN, which tells it to search
> in the executable's directory:
>
>   $ readelf -a testsuite/gdb.python/py-shared | grep ORIGIN
>    0x000000000000000f (RPATH)              Library rpath: [$ORIGIN]
>
> The problem with the IPA library is that it doesn't have an SONAME,
> making it very difficult to do testing on a remote board.  When a
> test executable is linked with it, it contains an absolute reference to
> the library path.  Therefore, unless the paths on the target are the
> same as on the build system, it won't work.

Yes, that is how fast tracepoint works for me.  My build and target have
the same directory hierarchy.  In fact, target /scratch is mounted to
build /scratch through nfs.  That is quite convenient, and don't need to
copy binaries and libraries from host to target.  However, this commit
breaks my testing.  It also breaks the typical testing with
native-gdbserver.  See https://sourceware.org/ml/gdb-testers/2016-q2/msg00162.html

>
> To make it possible for tests using the IPA library to run test on
> remote boards, I suggest adding an SONAME to libinproctrace.so.  I don't
> think it should be a big problem for users.  All the libraries installed
> on my system have an SONAME, so it should be fine if libinproctrace.so
> does too.

That is fine to add SONAME...

>
> As a consequence, native testing does not work anymore, since
> executables do not contain the absolute path to the library anymore.  To
> keep them working, we can have gdb_load_shlibs copy the library to the
> test directory when testing natively.  That's done by modifying
> gdb_load_shlibs.  We also have to add RPATH=$ORIGIN to executables, even
> when testing natively.

However, setting "RPATH=$ORIGIN" only works for your testing env,
because executable and libraries can be downloaded to the different
places on the target.

-- 
Yao (齐尧)