Prelinking on ARM with Debug Link

Mark Wielaard mjw@redhat.com
Wed Feb 10 16:17:00 GMT 2016


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



More information about the Systemtap mailing list