This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2 2/2] Make ftrace tests work with remote targets
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Mon, 11 Apr 2016 10:18:02 -0400
- Subject: Re: [PATCH v2 2/2] Make ftrace tests work with remote targets
- Authentication-results: sourceware.org; auth=none
- References: <1459794657-2087-1-git-send-email-simon dot marchi at ericsson dot com> <1459794657-2087-2-git-send-email-simon dot marchi at ericsson dot com> <8660vol272 dot fsf at gmail dot com>
On 16-04-11 09:12 AM, Yao Qi wrote:
> Simon Marchi <firstname.lastname@example.org> 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:
>> 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...
>> 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,