From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124576 invoked by alias); 30 Mar 2016 20:05:41 -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 123925 invoked by uid 89); 30 Mar 2016 20:05:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=forces, U*Torsten.Polle, Torsten.Polle@gmx.de, TorstenPollegmxde X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 30 Mar 2016 20:05:30 +0000 Received: from [192.168.2.99] ([188.108.74.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBIAz-1abhjQ3x1J-00AEVw; Wed, 30 Mar 2016 22:05:22 +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: Date: Wed, 30 Mar 2016 20:05:00 -0000 Cc: systemtap@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Mark Wielaard X-UI-Out-Filterresults: notjunk:1;V01:K0:mAxutsQgU8Y=:r2NfZc6mKrQQRq9a8Co0p6 AxyDHoaOzsWGTAHZqG7Nzp4PCbzaSroVrJvZPKj56Iwhmn5/gMrT1kfrVjKgAg35AVd74q++Y oxDZd0+2HOln6RGlMPL+e9SLJX8OHSjcRtDP/3Y1r9Fw+0tyye2gHXjMzxYcQZBIVgUj3W8kW XsY5AVcgdWxr4e419BBS7H5ekMOB559EojccX3xbs58HTPWBg/lGYWZS2yzchS5S5IDfoqVkN 7u2ookLgpP2m4gVoqhTRRx6gcU0dEChPwnyUx2FDexOaXcA8O1yE1J0QDn+uKwBCJqfbQY7/X 3mAKmL8gnYW8OV5NbpeEPOMLzND7ekjhhPGycGsP25Gt0kHUAV/iiMxr9JTacEDxE2p9nVXF5 rHoDs88kiKF4dIgNTXL/7G1LGV5cyJpdWVGtsr+gCizo1NLQlhPy0B2/xtd2OAxJjg1zPZRWF lLoN4YeB2HXLHsCbPRrQsXOwxb8y/6mRiMUc352+8NB7n3KvSaGc1zMCWa/EytrA51SfUHU6A pfulqX4M6gwLlXONFbzrI9S1d6M+KI6F4RJgAbJ0SOGTgRNH50iqw2Ea8xS7wFuA/SU6DkenA wJeK3ALV0F4uwNu3SocQJMVbCzAK0lyxiaBjVKuTvbMyG1xB5HtMz024y5QrcXwSmdp7DNWIf 1DOmBooH9ek9Hkzgmh8okjlbq5rK6+11a35yV9ciUxahTkXx/mnP4lVKXoADVCqglRJvA+Amo yzCqYH8zzhRY2SA6PioIR4X7wwA1lrREuZEdvGzTAifv7yeIGvPgOlA+um1RXz5h+UAq6YNIb c5mvYb6 X-IsSubscribed: yes X-SW-Source: 2016-q1/txt/msg00203.txt.bz2 > Am 28.02.2016 um 21:51 schrieb Torsten Polle : >=20 >=20 >> Am 23.02.2016 um 23:16 schrieb Torsten Polle : >>=20 >>=20 >>> 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 debug_= frame_off is 0 and dwbias is -1, the result is -1. As the arithmethics on t= he 64bit host is unsigned, the result is 0xffffffffffffffff in hex notation= and 18446744073709551615 in decimal notation. As stap-symbols.h is used fo= r the target, the values are too large for the 32bit wide unsigned int, whi= ch is the data type for the field sec_load_offset. Therefore the compiler c= omplains. The type cast to uint32_t forces the host compiler to use only a = 32bit value. Therefore the result is 0xffffffff (4294967295). At least that= is what happens on my host. I need the =E2=80=9Eu=E2=80=9C because even 42= 94967295 is considered to be too large. >>=20 >>>> I would like to double check in my environment if we could fall back t= o the hex notation again. >>>=20 >>> Isn't it simpler and consistent to just always use decimal in this case? >>> 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 notat= ion for the addresses. I hope to be able to check whether the hex notation = with casts works tomorrow and get back to you. >>=20 >> Regards, >> Torsten >=20 > Mark, >=20 > Please find a new version of the patch attached. I changed the patch to u= se hexadecimal numbers consistently. >=20 > Kind Regards, > Torsten > <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch> Mark, any comments or thoughts on my proposal? Kind Regards, Torsten