From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31455 invoked by alias); 26 Nov 2009 07:04:17 -0000 Received: (qmail 31443 invoked by uid 22791); 26 Nov 2009 07:04:16 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,MIME_CHARSET_FARAWAY,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f199.google.com (HELO mail-pz0-f199.google.com) (209.85.222.199) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Nov 2009 07:04:13 +0000 Received: by pzk37 with SMTP id 37so342955pzk.10 for ; Wed, 25 Nov 2009 23:04:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.66.13 with SMTP id o13mr939547wfa.307.1259219051473; Wed, 25 Nov 2009 23:04:11 -0800 (PST) In-Reply-To: <20091116182307.GA6377@localhost.localdomain> References: <1257410818.2529.6.camel@hermans.wildebeest.org> <20091105152546.GB21665@redhat.com> <20091105153606.GC21665@redhat.com> <20091105155425.GD21665@redhat.com> <20091116182307.GA6377@localhost.localdomain> Date: Thu, 26 Nov 2009 07:04:00 -0000 Message-ID: Subject: Re: Integer constant is too large for 'long' type From: naresh kamboju To: Eugeniy Meshcheryakov Cc: systemtap@sources.redhat.com, "Frank Ch. Eigler" , Dave Brolley , David Smith , Masami Hiramatsu Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2009-q4/txt/msg00716.txt.bz2 Hi, The following issue was noticed Issue: /tmp/stapkpgLTm/stap-symbols.h:60600: error: integer constant is too large for 'long' type /tmp/stapkpgLTm/stap-symbols.h:60600: error: large integer implicitly truncated to unsigned type >> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg690166.= html >>This patch was needed for kernels with CONFIG_RELOCATABLE set. I am not sure about the CONFIG_RELOCATABLE in ARM Kernels. Is this config option only for X86 and PowerPC? I have made following changes for the ARM architecture to over come the above build issues. Index: b/translate.cxx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- a/translate.cxx +++ b/translate.cxx @@ -4905,8 +4905,13 @@ dump_unwindsyms (Dwfl_Module *m, correct either. We may instead need a relocation basis different from _stext, such as __start_notes. */ if (modname =3D=3D "kernel") +#if 0 c->output << ".build_id_offset =3D 0x" << hex << build_id_vaddr - (base + extra_offset) << dec << ",\n"; +#else + c->output << ".build_id_offset =3D 0x" << hex << build_id_vaddr + << dec << ",\n"; +#endif else c->output << ".build_id_offset =3D 0x" << hex << build_id_vaddr - base >That's only the build issue. Does the code *run* though, meaning does >it actually verify the buildid bits at virtual address 0x0-ish on your arm kernel? I suspect not. I am not sure about how to verify the results. Please help me out in this context. However, I am able to build and staprun is working fine. #staprun five.ko Best regards Naresh Kamboju On Mon, Nov 16, 2009 at 11:53 PM, Eugeniy Meshcheryakov wrote: > 16 =CC=C9=D3=D4=CF=D0=C1=C4=C1 2009 =CF 21:14 +0530 naresh kamboju =CE=C1= =D0=C9=D3=C1=D7(-=CC=C1): >> However, I have back ported this patch and able to resolve the build >> issue on ARM. > > I assume that this means that you have reverted the patch. Is it > possible to load generated modules after that? Or does this only fix > compilation? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksBmIsACgkQKaC6+zmozOIVmwCgk361WR6KPs2Lvf+OSTEBcpdu > TZ0An08rPalwgz9O2D6rqjDMTrz6adBM > =3DcxSs > -----END PGP SIGNATURE----- > >