From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3459 invoked by alias); 5 Apr 2016 18:04:30 -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 3442 invoked by uid 89); 5 Apr 2016 18:04:29 -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=remotely 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; Tue, 05 Apr 2016 18:04:19 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.7F.22441.BFDF3075; Tue, 5 Apr 2016 20:03:39 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.248.2; Tue, 5 Apr 2016 14:04:16 -0400 Subject: Re: [PATCH v2 2/2] Make ftrace tests work with remote targets To: Pedro Alves , References: <1459794657-2087-1-git-send-email-simon.marchi@ericsson.com> <1459794657-2087-2-git-send-email-simon.marchi@ericsson.com> <5703FA82.4010708@redhat.com> From: Simon Marchi Message-ID: <5703FE20.3040801@ericsson.com> Date: Tue, 05 Apr 2016 18:04: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: <5703FA82.4010708@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00098.txt.bz2 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!