From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52872 invoked by alias); 11 Apr 2016 14:18:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 52855 invoked by uid 89); 11 Apr 2016 14:18:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy= X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 11 Apr 2016 14:18:06 +0000 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 84.9E.22441.4F1BB075; Mon, 11 Apr 2016 16:17:24 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.86) with Microsoft SMTP Server id 14.3.248.2; Mon, 11 Apr 2016 10:18:03 -0400 Subject: Re: [PATCH v2 2/2] Make ftrace tests work with remote targets To: Yao Qi References: <1459794657-2087-1-git-send-email-simon.marchi@ericsson.com> <1459794657-2087-2-git-send-email-simon.marchi@ericsson.com> <8660vol272.fsf@gmail.com> CC: , Pedro Alves From: Simon Marchi Message-ID: <570BB21A.7070301@ericsson.com> Date: Mon, 11 Apr 2016 14:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <8660vol272.fsf@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00210.txt.bz2 On 16-04-11 09:12 AM, Yao Qi wrote: > Simon Marchi 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