From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67016 invoked by alias); 5 Apr 2016 17:49:04 -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 67002 invoked by uid 89); 5 Apr 2016 17:49:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sidebyside, remotely X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 05 Apr 2016 17:48:53 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4CD25DB028; Tue, 5 Apr 2016 17:48:52 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u35HmoXs004530; Tue, 5 Apr 2016 13:48:51 -0400 Subject: Re: [PATCH v2 2/2] Make ftrace tests work with remote targets To: Simon Marchi , gdb-patches@sourceware.org References: <1459794657-2087-1-git-send-email-simon.marchi@ericsson.com> <1459794657-2087-2-git-send-email-simon.marchi@ericsson.com> From: Pedro Alves Message-ID: <5703FA82.4010708@redhat.com> Date: Tue, 05 Apr 2016 17:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1459794657-2087-2-git-send-email-simon.marchi@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00094.txt.bz2 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