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

Simon Marchi
2016-04-05T18:04:30Z

On 16-04-05 01:48 PM, Pedro Alves wrote:
> 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
>

Pushed as well, thanks!