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

Pedro Alves
2016-04-05T17:49:04Z

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