From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101480 invoked by alias); 10 Feb 2016 16:17:28 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 101380 invoked by uid 89); 10 Feb 2016 16:17:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:104, mixing, hacked, We'll X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 10 Feb 2016 16:17:25 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 6243114A81; Wed, 10 Feb 2016 16:17:24 +0000 (UTC) Received: from bordewijk.wildebeest.org (ovpn-113-77.phx2.redhat.com [10.3.113.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1AGHNna009907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Feb 2016 11:17:24 -0500 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id 2002C8145852; Wed, 10 Feb 2016 17:17:21 +0100 (CET) Message-ID: <1455121041.7606.104.camel@redhat.com> Subject: Re: Prelinking on ARM with Debug Link From: Mark Wielaard To: Torsten Polle Cc: systemtap@sourceware.org Date: Wed, 10 Feb 2016 16:17:00 -0000 In-Reply-To: <6E47DD0A-0515-45C6-86A1-4669A8182663@gmx.de> References: <4BCA4243-B16B-436F-9D53-41C551492A51@gmx.de> <6E47DD0A-0515-45C6-86A1-4669A8182663@gmx.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2016-q1/txt/msg00075.txt.bz2 Hi Torsten, On Tue, 2016-02-09 at 21:55 +0100, Torsten Polle wrote: > I=E2=80=99ve not received any answer on my posting. So I wonder whether t= he > 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[] =3D { { .name =3D ".dynamic", .size =3D 0x13b9e8, .symbols =3D _stp_module_1_symbols_0, .num_symbols =3D 0, #if defined(STP_USE_DWARF_UNWINDER) && defined(STP_NEED_UNWIND_DATA) .debug_hdr =3D _stp_module_1_debug_frame_hdr_0, .debug_hdr_len =3D 22604,=20 .sec_load_offset =3D 0xffffffffffffebc0 #else .debug_hdr =3D NULL, .debug_hdr_len =3D 0, .sec_load_offset =3D 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