From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12257 invoked by alias); 12 Jun 2015 12:40:16 -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 12246 invoked by uid 89); 12 Jun 2015 12:40:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 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; Fri, 12 Jun 2015 12:40:14 +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 A62FEC79DD; Fri, 12 Jun 2015 12:40:13 +0000 (UTC) Received: from bordewijk.wildebeest.org (ovpn-116-109.ams2.redhat.com [10.36.116.109]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5CCeCj5003112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jun 2015 08:40:13 -0400 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id B2554816307F; Fri, 12 Jun 2015 14:40:11 +0200 (CEST) Message-ID: <1434112811.3016.82.camel@bordewijk.wildebeest.org> Subject: Re: Prelinking on ARM From: Mark Wielaard To: Torsten Polle Cc: systemtap@sourceware.org Date: Fri, 12 Jun 2015 12:40:00 -0000 In-Reply-To: References: <1433269681.4538.237.camel@bordewijk.wildebeest.org> <3FE8FEB6-F65B-4F42-A963-30B8D216262B@gmx.de> <1433323679.4538.242.camel@bordewijk.wildebeest.org> <0FE2ADEE-8F4C-4205-A282-6BE15B8F00D5@gmx.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00151.txt.bz2 Hi Torsten, On Fri, 2015-06-05 at 21:55 +0200, Torsten Polle wrote: > >> I must admit to not have much experience with the > >> cross-compiling/cross-stapping mechanism. If you could provide a > >> small shared library (plus separate debuginfo file?) and the stap > >> invocation that doesn't work correctly that would be helpful for > >> understanding what goes wrong. >=20 > please find my example below. Unfortunately, I could not reproduce the > problem with a smaller library. The prelinked library and the debug > information is a little bit larger. >=20 > I set a function call and function return probe in function > "__libc_malloc". >=20 > In the prelinked file [1], the address is 0x410ddd94. The offset from the= load > address is 0x410ddd94 - 0x41068000 =3D 0x75D94 >=20 > But the offest given in the debug information is only 0x00074954. >=20 > The debug output from SystemTap [3] shows a pc of 0x74954 and a module bi= as > 0x41079440. That might, or might not, be correct. systemtap uses libdwfl to create a memory layout mimicking how the process/library may be placed in memory. It might pick a (fictional) load address for the library that is different than what the dynamic loader might pick (the prelinked load address). If so, that might explain the difference of module bias. It does look to me like the pc address that stap finds (0x74954) is correct for the malloc function you are trying to probe. Could you show the complete stap command line you are using? What do you expect the output is and what does the full output actually look like? Thanks, Mark