This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Prelinking on ARM with Debug Link
- From: Torsten Polle <Torsten dot Polle at gmx dot de>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Wed, 10 Feb 2016 21:12:35 +0100
- 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>
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