Re: Prelinking on ARM with Debug Link

[Torsten Polle <Torsten.Polle@gmx.de>]

Hi Mark,

Thanks for the answer.

> Am 10.02.2016 um 17:17 schrieb Mark Wielaard <mjw@redhat.com>:
> 
> Hi Torsten,
> 
> On Tue, 2016-02-09 at 21:55 +0100, Torsten Polle wrote:
>> I’ve not received any answer on my posting. So I wonder whether the
>> mail might have slipped your attention or there is any other
>> information you might need.
> 
> Sorry, I forgot about this issue.
> 
> It has been some time since I hacked on this code, so I don't
> immediately know what is going on. It would be nice to have a somewhat
> simpler reproducer. You use a large stap script using guru mode mixing
> user and kernel probes. Is all that really necessary to replicate the
> issue? Is the issue only triggered by the cross compiling?

Do you mean the example in my original mail or do you refer to the much simpler example from [1]?

> It seems the issue is this generated code from stap-symbols.h
> for /lib/libc-2.18.so:
> 
> static struct _stp_section _stp_module_1_sections[] = {
> {
> .name = ".dynamic",
> .size = 0x13b9e8,
> .symbols = _stp_module_1_symbols_0,
> .num_symbols = 0,
> #if defined(STP_USE_DWARF_UNWINDER) && defined(STP_NEED_UNWIND_DATA)
> .debug_hdr = _stp_module_1_debug_frame_hdr_0,
> .debug_hdr_len = 22604, 
> .sec_load_offset = 0xffffffffffffebc0
> #else
> .debug_hdr = NULL,
> .debug_hdr_len = 0,
> .sec_load_offset = 0
> #endif /* STP_USE_DWARF_UNWINDER && STP_NEED_UNWIND_DATA */
> },
> };
> 
> The .sec_load_offset went negative and produced a large hex output that
> doesn't fit. We'll have to find out if the issue is that the value
> became negative. Or whether the issue is that the generated value is too
> big for the (cross-compiled) field type. Or maybe both.

I made some feeble attempts to fix this issue, i.e. I tried to figure out whether the negative offset made any sense at all. But all attempts on my part failed so far. So any help is much appreciated.

> Cheers,
> 
> mark

Thanks,
Torsten

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