public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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

  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).