From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58586 invoked by alias); 2 Jun 2015 18:28:07 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 58560 invoked by uid 89); 2 Jun 2015 18:28:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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, 02 Jun 2015 18:28:05 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E9891AC7A6; Tue, 2 Jun 2015 18:28:03 +0000 (UTC) Received: from bordewijk.wildebeest.org (ovpn-116-45.ams2.redhat.com [10.36.116.45]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t52IS2qM002378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2015 14:28:03 -0400 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id 177AA8261811; Tue, 2 Jun 2015 20:28:01 +0200 (CEST) Message-ID: <1433269681.4538.237.camel@bordewijk.wildebeest.org> Subject: Re: Prelinking on ARM From: Mark Wielaard To: Torsten Polle Cc: systemtap@sourceware.org Date: Tue, 02 Jun 2015 18:28:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00128.txt.bz2 On Mon, 2015-06-01 at 22:43 +0200, Torsten Polle wrote: > I've a problem with prelinked shared and non-prelinked debug information > for the same on ARM. The relative offset to the .text section differs > for the prelinked shared library and the non-prelinked debug > information. SystemTap only compensates for the difference in the start > addresses. I tried to debug the problem, but I've to admit that the > problem is well over my head. Could someone give me a hint on this > matter? Does the testsuite/systemtap.exelib/exelib.exp test work for you? # Builds various variants of an executable and a shared library # (with gcc/g++, -O0/-O3, prelinked/pie, seperate debuginfo) # Then runs tests with a list of execs. # Don't enable all sub-tests by default, enable them separately when # you want to track down an issue. # Enable just the all-in-one test for regular test runs to safe time #set subtestlist {lib mark uname ustack cleanup} make installcheck RUNTESTFLAGS=3Dexelib.exp Which for me on an x86_64 and a armv7hl give: Snapshot: version 2.8/0.160, commit release-2.7-126-gf80d9cdb3078 GCC: 4.8.3 [gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)] Distro: Red Hat Enterprise Linux Workstation release 7.1 (Maipo) SElinux: Enforcing Running /home/mark/src/systemtap/testsuite/systemtap.exelib/exelib.exp ... =3D=3D=3D systemtap Summary =3D=3D=3D # of expected passes 376 Snapshot: version 2.8/0.161, commit release-2.7-160-g1eed3df165bc + changes GCC: 5.1.1 [gcc (GCC) 5.1.1 20150422 (Red Hat 5.1.1-1)] Distro: Fedora release 22 (Twenty Two) SElinux: Enforcing Running ./systemtap.exelib/exelib.exp ... =3D=3D=3D systemtap Summary =3D=3D=3D # of expected passes 188 (arm has half the number of passes since x86_64 actually does twice as many tests, for both normal 64bits binaries and for an -m32 binaries.) If the above doesn't match what you see on your setup could you enable the subtests as indicated in the .exp file and see which particular subtests fail (maybe include the relevant parts of the testsuite/systemtap.log file). Thanks, Mark