From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9814 invoked by alias); 16 Feb 2016 10:08:38 -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 9774 invoked by uid 89); 16 Feb 2016 10:08:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1578, guru 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, 16 Feb 2016 10:08:36 +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 3CADDC4096; Tue, 16 Feb 2016 10:08:35 +0000 (UTC) Received: from bordewijk.wildebeest.org (ovpn-113-30.phx2.redhat.com [10.3.113.30]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1GA8XFi030588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Feb 2016 05:08:34 -0500 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id E83338145852; Tue, 16 Feb 2016 11:08:32 +0100 (CET) Message-ID: <1455617312.9915.50.camel@redhat.com> Subject: Re: Aw: Re: Prelinking on ARM with Debug Link From: Mark Wielaard To: Torsten Polle Cc: systemtap@sourceware.org Date: Tue, 16 Feb 2016 10:08:00 -0000 In-Reply-To: References: <4BCA4243-B16B-436F-9D53-41C551492A51@gmx.de> <6E47DD0A-0515-45C6-86A1-4669A8182663@gmx.de> <1455121041.7606.104.camel@redhat.com> <3855EE25-54F2-47FB-88A8-FF1EC3963C06@gmx.de> , <1455136517.7606.107.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2016-q1/txt/msg00089.txt.bz2 On Thu, 2016-02-11 at 11:49 +0100, Torsten Polle wrote: > > On Wed, 2016-02-10 at 21:12 +0100, Torsten Polle wrote: > > > > Am 10.02.2016 um 17:17 schrieb Mark Wielaard : > > Maybe I am not reading the simpler example correctly. > > But it looked like it was still mixing user and kernel probes, used guru > > mode and cross compiling. Are all of those factors needed to trigger the > > bug? > >=20 > > If at all possible just one simple probe against libc.so to show what is > > going wrong would be ideal. >=20=20 > Please find a simplified example attached. It's not the probe itself but = rather > the fact that I include unwind information for libc-2.18.so. >=20 > I also found another combination that triggers the error. If the script l= ooks as follows >=20 > probe never > { > print_ubacktrace(); > } >=20 > probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourc= ery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").call > { > printf("call\n"); > } > probe process("/lib/libc-2.18.so").function("__libc_malloc@/opt/codesourc= ery/arm-none-linux-gnueabi/src/glibc/malloc/malloc.c").return > { > printf("return\n"); > } >=20 > I don't need the -d option. OK. Which other options are necessary? In particular in your cmd.sh you seem to be using -a arm -B CROSS_COMPILE=3Darm-none-linux-gnueabi- and -B CONFIG_DEBUG_INFO=3Dy Is there a reason to use those options to reproduce the issue? I am particularly trying to figure out if you need or are using a cross build and if so between which architectures. Thanks, Mark