Re: Prelinking on ARM with Debug Link

[Mark Wielaard <mjw at redhat dot 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?

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.

Cheers,

mark