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

Simon Marchi
2016-04-11T14:18:17Z

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