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

[Simon Marchi <simon.marchi@ericsson.com>]

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!