From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110775 invoked by alias); 1 Apr 2016 13:07:54 -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 110754 invoked by uid 89); 1 Apr 2016 13:07:53 -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,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=forgotten, Hx-languages-length:2837 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, 01 Apr 2016 13:07:42 +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 3E84CD4798; Fri, 1 Apr 2016 13:07:41 +0000 (UTC) Received: from bordewijk.wildebeest.org (ovpn-113-59.phx2.redhat.com [10.3.113.59]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u31D7de2009923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Apr 2016 09:07:40 -0400 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id 0D7C38148038; Fri, 1 Apr 2016 15:07:38 +0200 (CEST) Message-ID: <1459516058.8147.138.camel@redhat.com> Subject: Re: Prelinking on ARM with Debug Link From: Mark Wielaard To: Torsten Polle Cc: systemtap@sourceware.org Date: Fri, 01 Apr 2016 13:07:00 -0000 In-Reply-To: <8BE9FE12-777D-4C56-89C0-26FC2718CCAE@gmx.de> 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2016-q2/txt/msg00000.txt.bz2 Hi Torsten, On Wed, 2016-03-30 at 22:05 +0200, Torsten Polle wrote: > > Am 28.02.2016 um 21:51 schrieb Torsten Polle :=20 > >> Am 23.02.2016 um 23:16 schrieb Torsten Polle : > >>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard : > >>>=20 > >>> On Mon, 2016-02-22 at 22:45 +0100, Torsten Polle wrote: > >>>> the principle idea of your patch works. But I had to rewrite it to > >>>> really work in my environment. Could you please have a look at my > >>>> proposal? Would something like that be acceptable? > >>>=20 > >>> Could you give an example of what didn't work? > >>> You cast both debug_frame_off and dwbias to uint32_t before > >>> substracting. Is that really necessary/correct? Both are Dwarf_Addrs > >>> which are always uint64_t. And we care about the difference here. > >>=20 > >> In my case debug_frame_off is larger than dwbias. If for instance debu= g_frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on= the 64bit host is unsigned, the result is 0xffffffffffffffff in hex notati= on and 18446744073709551615 in decimal notation. As stap-symbols.h is used = for the target, the values are too large for the 32bit wide unsigned int, w= hich is the data type for the field sec_load_offset. Therefore the compiler= complains. The type cast to uint32_t forces the host compiler to use only = a 32bit value. Therefore the result is 0xffffffff (4294967295). At least th= at is what happens on my host. I need the =E2=80=9Eu=E2=80=9C because even = 4294967295 is considered to be too large. > >>=20 > >>>> I would like to double check in my environment if we could fall back= to the hex notation again. > >>>=20 > >>> Isn't it simpler and consistent to just always use decimal in this ca= se? > >>> There should at least be a comment why we use a different notation for > >>> elf32 vs elf64 targets. > >>=20 > >> I would go for a consistent notation. Personally, I prefer the hex not= ation for the addresses. I hope to be able to check whether the hex notatio= n with casts works tomorrow and get back to you. > > > Please find a new version of the patch attached. I changed the patch to= use hexadecimal numbers consistently. > >=20 > > Kind Regards, > > Torsten > > <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch> > > any comments or thoughts on my proposal? Sorry I had forgotten about this issue. In your example you have a debug_frame_off with zero and a dwbias of -1. That looks somewhat suspicious. Are we sure that isn't a special case? A debug_frame_off of zero seems to indicate that there isn't a debug_frame in the first place. dwbias being -1 might indicate that dwfl_module_getdwarf () failed. We don't seem to check whether the call succeeds. Could you try and see if any of the above is the case in your situation? Thanks, Mark