This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Prelinking on ARM with Debug Link
- From: Mark Wielaard <mjw at redhat dot com>
- To: Torsten Polle <Torsten dot Polle at gmx dot de>
- Cc: systemtap at sourceware dot org
- Date: Fri, 01 Apr 2016 15:07:38 +0200
- Subject: Re: Prelinking on ARM with Debug Link
- Authentication-results: sourceware.org; auth=none
- References: <4BCA4243-B16B-436F-9D53-41C551492A51 at gmx dot de> <6E47DD0A-0515-45C6-86A1-4669A8182663 at gmx dot de> <1455121041 dot 7606 dot 104 dot camel at redhat dot com> <3855EE25-54F2-47FB-88A8-FF1EC3963C06 at gmx dot de> <1455136517 dot 7606 dot 107 dot camel at redhat dot com> <trinity-fb9190d9-ee29-4674-8066-0251f630d69b-1455187752264 at 3capp-gmx-bs27> <1455617312 dot 9915 dot 50 dot camel at redhat dot com> <1FF3B18B-EEA4-4A00-8E4F-3B7977E0111C at gmx dot de> <1455812509 dot 7770 dot 4 dot camel at redhat dot com> <23DAF1AA-DD74-4B03-8290-A4CB49F10D14 at gmx dot de> <1456246011 dot 7770 dot 120 dot camel at redhat dot com> <97BC1582-878D-4841-9D3B-B0C50A017B1B at gmx dot de> <CBF70205-25B4-4972-8AB5-BC6357618455 at gmx dot de> <8BE9FE12-777D-4C56-89C0-26FC2718CCAE at gmx dot de>
Hi Torsten,
On Wed, 2016-03-30 at 22:05 +0200, Torsten Polle wrote:
> > 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.
>
> > 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>
>
> 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