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

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 16-04-11 09:12 AM, Yao Qi wrote:
> 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.

I agree it's convenient, and I have a similar setup (although with sshfs), but I
don't think it should be a requirement.  For some people it might not be possible
or easy to mount the same paths on both systems.

> 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

Right, that's because the native-gdbserver board advertises itself as being remote, but
overrides the _download procedure to be a no-op (see gdbserver-base.exp).  So, the
libinproctrace.exp file is not copied to the output directory.

That test passes if you apply:

https://sourceware.org/ml/gdb-patches/2016-04/msg00112.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...

Ok.

>>
>> 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.

When running the testsuite?  In which cases does this happen?

All solib tests rely on RPATH=$ORIGIN and the executable being uploaded at
the same location than the libraries, don't they?  Why should it be different
for ftrace tests?

Thanks for the feedback,

Simon