From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116875 invoked by alias); 23 Feb 2016 22:16:37 -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 116865 invoked by uid 89); 23 Feb 2016 22:16:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1798, complains, sec_load_offset, H*f:sk:1456246 X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Feb 2016 22:16:36 +0000 Received: from [192.168.2.99] ([188.96.13.44]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LqQTl-1a3fKc2Xfl-00e0kS; Tue, 23 Feb 2016 23:16:27 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Prelinking on ARM with Debug Link From: Torsten Polle In-Reply-To: <1456246011.7770.120.camel@redhat.com> Date: Tue, 23 Feb 2016 22:16:00 -0000 Cc: systemtap@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <97BC1582-878D-4841-9D3B-B0C50A017B1B@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> To: Mark Wielaard X-UI-Out-Filterresults: notjunk:1;V01:K0:f7OMac9d2Mg=:+W59c0PRSou/w2NSihSj8I Y+v+0ShwzzSgrB3lWrrjqMbV9wAzXC+aiblt3VxZFwJ5yN/dVKwiBsmXE/6akUT9IEKWl35+e PpgD0hbIaLExa/WGPz7rcFfi3/xu2usVLf9rzlhAD5nvl5pwdhxK6WuIoownYeTZwuqR5+VlR inPvNMvxRj1HUJhZnQxNhdXCRL5ltTbeYTjD8y2ab1UNRw6edntERt1GXNun+kQ39ZU/TQBJE gUur+5To9qayKMAAOhsr6zJbuhgrEifnOfX2QSaBFj9cKIH9FUr1LPaHULlhm75Iz/X9YzXZe QeucgMC9D9HbLdm6m7jIic/mj5fAckrQkGwJe/iwSFTibTOZ3G+6hy4FDEYHQZFe4UJi6AYLx WMkCggKsJwIZE0gbBe2peXFurZJ9Eu6yQUH/eOcbgmU1tSymMHkMpnVjowpAQm1AqGBr0LuBf +FYqiAqM7vPCdsi3qatDP/7m/HfhNR6q9ps0VXmMzCoAD71qsJKATBy03E08sdFd/JSmJx5LZ 0dgo0rtV4nsaE4UPmIIw9N9OoOtiTKySTdoghLPVs1kYvJIspYDkAJR4nHNmSCQO9uc2yPqsR GJzKRF/4Qj7AOL1BR8P4ektpNXWMrMNZ1zgaXtZoTuaf0UqtlcJTRHEQQHn9p1G3ytSeXM4bi Fjk/7WtqRZpTDEGYgBiwnbGGvhi/nLIhz+aINoYqbsotYU/aJfQImjaEjhDfxHmCEalHUaz4i LfTGM5Xd+HSR11YSniUlrgpkiToXe6u0UC10U19wylQ86kAw1RYOi5+DZncZz9hUdLQsAIOk6 Y7J1O89 X-SW-Source: 2016-q1/txt/msg00116.txt.bz2 > 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. In my case debug_frame_off is larger than dwbias. If for instance debug_fra= me_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 notation an= d 18446744073709551615 in decimal notation. As stap-symbols.h is used for t= he target, the values are too large for the 32bit wide unsigned int, which = is the data type for the field sec_load_offset. Therefore the compiler comp= lains. The type cast to uint32_t forces the host compiler to use only a 32b= it 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 42949= 67295 is considered to be too large. >> 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 case? > There should at least be a comment why we use a different notation for > elf32 vs elf64 targets. I would go for a consistent notation. Personally, I prefer the hex notation= for the addresses. I hope to be able to check whether the hex notation wit= h casts works tomorrow and get back to you. Regards, Torsten