From: Torsten Polle <Torsten.Polle@gmx.de>
To: Mark Wielaard <mjw@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: Prelinking on ARM with Debug Link
Date: Wed, 30 Mar 2016 20:05:00 -0000 [thread overview]
Message-ID: <8BE9FE12-777D-4C56-89C0-26FC2718CCAE@gmx.de> (raw)
In-Reply-To: <CBF70205-25B4-4972-8AB5-BC6357618455@gmx.de>
> Am 28.02.2016 um 21:51 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
>
>
>> Am 23.02.2016 um 23:16 schrieb Torsten Polle <Torsten.Polle@gmx.de>:
>>
>>
>>> Am 23.02.2016 um 17:46 schrieb Mark Wielaard <mjw@redhat.com>:
>>>
>>> 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?
>>>
>>> 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_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 notation 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, which 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 that is what happens on my host. I need the „u“ because even 4294967295 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.
>>>
>>> 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 with casts works tomorrow and get back to you.
>>
>> Regards,
>> Torsten
>
> Mark,
>
> Please find a new version of the patch attached. I changed the patch to use hexadecimal numbers consistently.
>
> Kind Regards,
> Torsten
> <0001-PATCH-v2-Fix-Compilation-fails-for-prelinked-librari.patch>
Mark,
any comments or thoughts on my proposal?
Kind Regards,
Torsten
next prev parent reply other threads:[~2016-03-30 20:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 19:29 Torsten Polle
2016-02-09 20:55 ` Torsten Polle
2016-02-10 16:17 ` Mark Wielaard
2016-02-10 20:12 ` Torsten Polle
2016-02-10 20:35 ` Mark Wielaard
2016-02-11 10:49 ` Aw: " Torsten Polle
2016-02-16 10:08 ` Mark Wielaard
2016-02-16 20:46 ` Torsten Polle
2016-02-18 16:21 ` Mark Wielaard
2016-02-22 21:45 ` Torsten Polle
2016-02-23 16:46 ` Mark Wielaard
2016-02-23 22:16 ` Torsten Polle
2016-02-28 20:51 ` Torsten Polle
2016-03-30 20:05 ` Torsten Polle [this message]
2016-04-01 13:07 ` Mark Wielaard
2016-04-01 21:19 ` Torsten Polle
2016-04-05 13:44 ` Mark Wielaard
2016-04-06 20:45 ` Torsten Polle
2016-04-06 21:56 ` Mark Wielaard
2016-04-11 18:47 ` Torsten Polle
2016-04-11 21:02 ` Mark Wielaard
2016-04-12 20:26 ` Torsten Polle
2016-04-13 9:25 ` Mark Wielaard
2016-04-13 14:36 ` Aw: " Torsten Polle
-- strict thread matches above, loose matches on Subject: below --
2015-12-01 7:26 Torsten Polle
2015-11-25 20:52 Torsten Polle
2015-11-26 10:33 ` Mark Wielaard
2015-11-26 22:05 ` Torsten Polle
2015-11-27 8:05 ` Mark Wielaard
2015-11-27 12:57 ` Torsten Polle
2015-11-27 15:06 ` Mark Wielaard
2015-11-27 16:34 ` Mark Wielaard
2015-11-27 20:08 ` Torsten Polle
2015-11-27 20:01 ` Torsten Polle
2015-11-30 19:26 ` David Smith
2015-12-01 20:10 ` Torsten Polle
2015-12-10 19:00 ` David Smith
2015-12-10 19:45 ` Torsten Polle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8BE9FE12-777D-4C56-89C0-26FC2718CCAE@gmx.de \
--to=torsten.polle@gmx.de \
--cc=mjw@redhat.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).