From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66035 invoked by alias); 11 Apr 2016 18:47:13 -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 66026 invoked by uid 89); 11 Apr 2016 18:47:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*gmx.de, 5184, hear X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 11 Apr 2016 18:47:11 +0000 Received: from [192.168.2.99] ([188.108.74.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MhRUQ-1bB3VE3wdG-00McO2; Mon, 11 Apr 2016 20:47:03 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Prelinking on ARM with Debug Link From: Torsten Polle In-Reply-To: <1459979805.8147.274.camel@redhat.com> Date: Mon, 11 Apr 2016 18:47:00 -0000 Cc: systemtap@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1455617312.9915.50.camel@redhat.com> <1FF3B18B-EEA4-4A00-8E4F-3B7977E0111C@gmx.de> <1455812509.7770.4.camel@redhat.com> <23DAF1AA-DD74-4B03-8290-A4CB49F10D14@gmx.de> <1456246011.7770.120.camel@redhat.com> <97BC1582-878D-4841-9D3B-B0C50A017B1B@gmx.de> <8BE9FE12-777D-4C56-89C0-26FC2718CCAE@gmx.de> <1459516058.8147.138.camel@redhat.com> <1459863878.8147.242.camel@redhat.com> <1459979805.8147.274.camel@redhat.com> To: Mark Wielaard X-UI-Out-Filterresults: notjunk:1;V01:K0:/LDr2zA8sg0=:ZmKhNCBctet6TY00nJegpW 6ekSuSCVDT0w8Kfp0qM2cmbVH6BtLTtmBqIy4B9/0bqr0dNA0sjtr0Sk/suRF56zJLoREegCb XRUvYCv3bDuVfofPWhbcSvxtqlEkAwVtI1nXS79p6PUU8G6HhaNtzt66VACLIjdE3/BWL/wO6 R8PV5nKGimt/G4/+sjkkoLy47uP8k9BwJO4hwIxmuSc5YxjQ6FDBuDAoP+7sO9LqaIBH+O0k+ 8Ii2gP7x0ZnEwKDueH7TL2br9bcc07bfcxao0moV9Bs7dH7UXjD6FAi8eCgg5Yo2wkdn1UXDN r9knhI5x4x1ju7KvmrEz9c1Z6XZZjAlAJ74y4yeQ1OMTY79Wkrx95uCluDxqq0BUpNBSRQrgk b60P5/Zz9Un7RkKjapoep6gYaKHMBYXiFWVAbFyRrcilc1fokBuj2UFIvFG+PJnXK7FLSzhH6 WFs21gMig9BDptAIjyNNZ4qmapXpSm/xmaLcY1cQIvnD0k9twdXbxLKlmNfm+6aq+Sgq8JK9Z 6ZwEVPtxPp0imRrZWBVO6tu5PaEIdE+Bw1bPmM7wvYi1S3fEN2tUcfzRBYitE0ctFZnyn10Ek VgTECkwkzIBETuv+WA9DFhooKpRccrVFQwaQp4JR+je6A6jRCBhQB+YlvP3p+ReNa3lCxFdNS LivY3qEbZoDfaP87weQ+4Xnh3dyKKXYf6ZhMFi3ItL2JNu9HhGb108Pjl5HH9goBwG5Q8Wm2J uu9P6lMaOAMGUeqTA+CnU5aUafGBrGySLzleOjFRgI5MOrDssU7jxS+utnIE1+8CnyjCpTWVS Ccs3QXo X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00024.txt.bz2 Hi Mark, > Am 06.04.2016 um 23:56 schrieb Mark Wielaard : >=20 > On Wed, 2016-04-06 at 22:44 +0200, Torsten Polle wrote: >>> Am 05.04.2016 um 15:44 schrieb Mark Wielaard : >>> runtime/unwind.c (adjustStartLoc): >>>=20 >>> if (is_ehframe) >>> return startLoc + vm_addr; >>> else >>> return startLoc + vm_addr - s->sec_load_offset; >>=20 >> I had twiddled with the else branch in the past. I do not recall all >> attempts. But I=E2=80=99m sure that I set sec_load_offset even to 0. The >> result is that the probes are set at the wrong address in libc. To be >> more concrete they are offset by -5184 compared to the original >> address. Still I=E2=80=99ll check your patch and let you know the result. >=20 > This code is certainly confusing. And arm32 might have different > defaults from all other architectures (which normally have .eh_frames > instead of just .debug_frames, on arm32 unwinding is often done through > EXIDX - exception index tables - instead, but stap doesn't support > those). So it might indeed be that in your case the non-ehframe path is > taken. But I believe that even in that sec_load_offset should be zero. I=E2=80=99ve checked your patch. As a result the backtrace calculations bre= ak in my environment. I=E2=80=99ve therefore instrumented adjustStartLoc() as follows: if (is_ehframe) { printk(KERN_ERR "eh: s=3D%lu, v=3D%lu, l=3D%lu\n", startLoc, vm_addr, s= ->sec_load_offset); return startLoc + vm_addr; } else { printk(KERN_ERR "no eh: s=3D%lu, v=3D%lu, l=3D%lu\n", startLoc, vm_addr= , s->sec_load_offset); return startLoc + vm_addr - s->sec_load_offset; } As a result I get the following output: [ 1215.876537] no eh: s=3D297684, v=3D1307279360, l=3D4294962112 [ 1215.876542] no eh: s=3D297532, v=3D1307279360, l=3D4294962112 [ 1215.876546] no eh: s=3D297568, v=3D1307279360, l=3D4294962112 [ 1215.876551] no eh: s=3D297612, v=3D1307279360, l=3D4294962112 [ 1215.876555] no eh: s=3D297612, v=3D1307279360, l=3D4294962112 [ 1215.876560] no eh: s=3D297612, v=3D1307279360, l=3D4294962112 This means that the non-ehframe path is taken and that sec_load_offset is n= on-zero. > So it might impact unwinding through user space shared libraries. But it > should not impact setting probe points in shared libraries. >=20 > On my own setup (x86_64 native) the patch showed no regressions with > make installcheck. I would be interesting to hear of any test results > you get with my patch. >=20 > Thanks, >=20 > Mark Regards, Torsten