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

[Pedro Alves <palves@redhat.com>]

On 04/04/2016 07:30 PM, Simon Marchi wrote:
> When we build a shared library for testing, it is built differently
> whether it is meant for the local system or a remote one.  When it is
> for the local system, the library is built with no SONAME.  So when the
> executable is built, roughly in this way:
> 
>   $ gcc testfile.c /path/to/library.so
> 
> the executable will contain an absolute reference to the library.  For
> example:
> 
>   $ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
>    0x0000000000000001 (NEEDED)             Shared library: [/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.python/py-shared-sl.sl]
> 
> When testing is done remotely, the absolute path obviously doesn't work.
> Therefore, we build the library with an SONAME:
> 
>   $ readelf -a testsuite/gdb.python/py-shared-sl.sl | grep SONAME
>    0x000000000000000e (SONAME)             Library soname: [py-shared-sl.sl]
> 
> which ends up in the executable's NEEDED field:
> 
>   $ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
>    0x0000000000000001 (NEEDED)             Shared library: [py-shared-sl.sl]
> 
> 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.
> 
> 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.
> 
> 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.
> 
> I think it's a good change in general, as it reduces the differences
> between testing a native and a remote target.  To further reduce those
> differences, we can also always build test shared libraries with an
> SONAME.
> 
> ftrace.exp and ftrace-lock.exp need to be modified slightly.  The code
> checks that the IPA library is loaded using the absolute path on the
> build machine.  That obviously doesn't work if the test is done
> remotely, as the path will be different.  I changed the tests to only
> search for the library basename (e.g. libinproctrace.so).
> 
> gdb/gdbserver/ChangeLog:
> 
> 	* Makefile.in ($(IPA_LIB)): Set SONAME of the IPA lib.
> 
> gdb/testsuite/ChangeLog:
> 
> 	* gdb.trace/ftrace-lock.exp: Check for IPA basename instead of
> 	absolute.
> 	* gdb.trace/ftrace.exp: Likewise.
> 	* lib/gdb.exp (gdb_compile): Set rpath $ORIGIN for non-remote
> 	targets as well.
> 	(gdb_compile_shlib): Set SONAME for non-remote targets as well.
> 	(gdb_load_shlibs): Copy libraries to test directory when testing
> 	natively.  Only set solib-search-path if testing remotely.
> 	* lib/mi-support.exp (mi_load_shlibs): Likewise.

OK.

Thanks,
Pedro Alves