Re: Prelinking on ARM with Debug Link

[Torsten Polle <Torsten dot Polle at gmx dot de>]

> Am 01.04.2016 um 15:07 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> 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?

No, this is not a special case. Itâs just a simplified example to illustrate the calculations. ;-)

In my initial mail [1], you can see the original values and calculations.

> The offending line in stap-symbols.h looks as follows:
> .sec_load_offset = 0xffffffffffffebc0 /* 4dec8000 4dec9440 */

The values in the comment are the result of the following instrumentation.

>                  Dwarf_Addr dwbias = 0;
>                  dwfl_module_getdwarf (m, &dwbias);
>                  c->output << ".sec_load_offset = 0x"
>                                    << hex << debug_frame_off - dwbias << dec
>                                    << "/* "  << hex << debug_frame_off << " " << dwbias << dec << "*/"
>                                    << "\n";

This means the actual values are 
debug_frame_off = 0x4dec8000
dwbias          = 0x4dec9440

> The offset of the .text section in the non-prelinked library is 0x15c40. 
> The offset of the .text section in the prelinked library is 0x4decf080 - 0xdeb8000 = 0x17080.
> 
> This means that .sec_load_offset is exactly the difference 0x15c40 - 0x17080 ~ 0xffffffffffffebc0.

You can find the results from a very simple reproduction in [2].

Thanks,
Torsten

[1] https://sourceware.org/ml/systemtap/2015-q4/msg00171.html
[2] https://sourceware.org/ml/systemtap/2015-q4/msg00219.html