From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22203 invoked by alias); 16 Nov 2009 15:45:51 -0000 Received: (qmail 22190 invoked by uid 22791); 16 Nov 2009 15:45:48 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f200.google.com (HELO mail-px0-f200.google.com) (209.85.216.200) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 15:44:53 +0000 Received: by pxi38 with SMTP id 38so491648pxi.10 for ; Mon, 16 Nov 2009 07:44:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.137.2 with SMTP id p2mr843704wfn.318.1258386292142; Mon, 16 Nov 2009 07:44:52 -0800 (PST) In-Reply-To: References: <1257410818.2529.6.camel@hermans.wildebeest.org> <20091105152546.GB21665@redhat.com> <20091105153606.GC21665@redhat.com> <20091105155425.GD21665@redhat.com> Date: Mon, 16 Nov 2009 15:45:00 -0000 Message-ID: Subject: Re: Integer constant is too large for 'long' type From: naresh kamboju To: systemtap@sources.redhat.com Cc: "Frank Ch. Eigler" , Dave Brolley , David Smith , Masami Hiramatsu , eugen@debian.org Content-Type: text/plain; charset=windows-1252 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/msg00533.txt.bz2 Hi, On Thu, Nov 5, 2009 at 9:39 PM, naresh kamboju wr= ote: > Hi, > > On Thu, Nov 5, 2009 at 9:24 PM, Frank Ch. Eigler wrote: >> Hi - >> >> On Thu, Nov 05, 2009 at 09:18:28PM +0530, naresh kamboju wrote: >> >> >> OK, the above shows that the linker script that is creating your arm >> kernel images is putting the build-id note in a weird place - at the >> very beginning of RAM, far away from .text and friends. =A0My guess is >> that this memory is actually not preserved at run time, so that even >> if we got the systemtap-time offsets all compiled in, the run-time >> value would not match. > OK. >> >> On more typical desktop linux builds, the build-id section is placed >> right after .text, so that relative to the _stext symbol, there is a >> smallish positive offset. =A0And that way the buildid bits get >> preserved. =A0Can you check whether this is fixable in the arm kernel >> you are using? > >> I'll check at my end with arm Kernel. After our discussion I have investigated this issue 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 Found the patch is applied to SystemTap-0.9.9 is causing the build issues in test cases of SystemTap testsuite. http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg690166.html translate.cxx: c->output << ".build_id_offset =3D 0x" << hex << build_id_vaddr - (base + extra_offset) << dec << ",\n"; In the above line, extra_offset datatype is "long long int" but ".build_id_offset is "unsigned long" only. Due to that it is giving "error: integer constant is too large for 'long' type" and the structure static struct _stp_module where =93.build_id_offset =3D 0xffffffff3fff8024=94 is filled with larger value in to =93unsigned long build_id_offset;=94 =46rom ".build_id_offset", this gives the offset value when relocations are applied to build id address in systemtap. In this scenario, build_id_vaddr itself supply the clear symbol relocation but I do not know why " build_id_vaddr - (base + extra_offset)" is done for relocations. I expect, (base + extra_offset) is subtracted from build_id_vaddr which assumes that offset between _stext and build is the same after relocation. However, I have back ported this patch and able to resolve the build issue on ARM. Please provide your comments. Best regards, Naresh Kamboju > > Thank you very much. > > Best regards > Naresh Kamboju > >> >> - FChE >>