This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Integer constant is too large for 'long' type
Hi,
On Thu, Nov 5, 2009 at 4:12 PM, naresh kamboju <naresh.kernel@gmail.com> wrote:
> Hi Mark,
>
> On Thu, Nov 5, 2009 at 2:16 PM, Mark Wielaard <mjw@redhat.com> wrote:
>> Hi Naresh,
>>
>> On Thu, 2009-11-05 at 14:10 +0530, naresh kamboju wrote:
>>> # stap -a arm -B CROSS_COMPILE=/usr/local/arm/cross/devel/bin/arm-dev-
>>> -p4 ?-r 2.6.29.4-kzm-arm11-g8de6eff -m five five.stp ?-vv
>>> SystemTap translator/driver (version 1.0/0.137 non-git sources)
>>
>> 0.137 is a pretty old version of elfutils, you might want to upgrade to
>> something newer.
>>
>
> yes. it is older version.
> i have selected this version because in the previous discussion links
> they have over come few of errors by using elfutils 0.137 version as
> per the below link
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=9738
>
> however. suggest me the best compatible version of elfutils with SystemTap-1.0 .
>
>>> In file included from /tmp/stapBF1Ti1/five.c:754:
>>> /tmp/stapBF1Ti1/stap-symbols.h:66980: error: integer constant is too
>>> large for 'long' type
>>> /tmp/stapBF1Ti1/stap-symbols.h:66980: error: large integer implicitly
>>> truncated to unsigned type
>>
>> Could you build with stap -k, which keeps the temporary file, and post
>> what code is around stap-symbols.h:66980?
>
> i'll try with "stap -k" and debug the issue.
As per your instructions I have build stap with –k option and
compiled with latest elfutils 0.143
found the /tmp/stapxxx directory and related file.
I can reproduce the same issue.
Observation:
----------------
In the below the structure "static struct _stp_module" where
“.build_id_offset = 0xffffffff3fff8024” is filled with larger value in to
“unsigned long build_id_offset;”
/****************************************************/
# stap -a arm -B CROSS_COMPILE=/usr/local/arm/cross/devel/bin/arm-dev-
-p4 -vv -k -r 2.6.29.4-alp_nl-kzm-arm11-g2542246 -m five five.stp
/****************************************************/
SystemTap translator/driver (version 1.0/0.143 non-git sources)
Copyright (C) 2005-2009 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
Session arch: arm release: 2.6.29.4-kzm-arm11-g2542246
Created temporary directory "/tmp/stap45yApj"
Searched '/usr/local/arm /cross/devel/share/systemtap/tapset/*.stp', found 56
Pass 1: parsed user script and 56 library script(s) in 130usr/10sys/156real ms.
probe schedule@kernel/sched.c:4699 kernel reloc=.dynamic pc=0xc031a7d4
probe schedule@kernel/sched.c:4699 kernel reloc=.dynamic pc=0xc031a7d4
Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 0
global(s) in 230usr/20sys/249real ms.
function recursion-analysis: max-nesting 0 non-recursive
probe_1784 locks nothing
probe_1785 locks nothing
dump_unwindsyms kernel index=0 base=0x0
Found build-id in kernel, length 20, end at 0x24
Pass 3: translated to C into "/tmp/stap45yApj/five.c" in
300usr/10sys/307real ms.
Running make -C
"/lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build"
M="/tmp/stap45yApj" ARCH="arm" "CROSS_COMPILE=/usr/local/arm
/cross/devel/bin/arm-dev-" modules --no-print-directory
CC [M] /tmp/stap45yApj/five.o
cc1: warnings being treated as errors
In file included from /tmp/stap45yApj/five.c:754:
/tmp/stap45yApj/stap-symbols.h:67606: error: integer constant is too
large for 'long' type
/tmp/stap45yApj/stap-symbols.h:67606: error: large integer implicitly
truncated to unsigned type
make[1]: *** [/tmp/stap45yApj/five.o] Error 1
make: *** [_module_/tmp/stap45yApj] Error 2
Pass 4: compiled C into "five.ko" in 1570usr/410sys/1985real ms.
Pass 4: compilation failed. Try again with another '--vp 0001' option.
Keeping temporary directory "/tmp/stap45yApj"
/****************************************************/
#vim /tmp/stapxz4QGI/stap-symbols.h +67606
/****************************************************/
static struct _stp_module _stp_module_0 = {
.name = "kernel",
.path = "/home/naresh/linux-2.6.29.y-BRANCH_SS/vmlinux",
.dwarf_module_base = 0x0,
.eh_frame_addr = 0x0,
#if defined(STP_USE_DWARF_UNWINDER) && defined(STP_NEED_UNWIND_DATA)
.debug_frame = _stp_module_0_debug_frame,
.debug_frame_len = 493784,
#else
.debug_frame = NULL,
.debug_frame_len = 0,
#endif /* STP_USE_DWARF_UNWINDER && STP_NEED_UNWIND_DATA*/
.eh_frame = NULL,
.eh_frame_len = 0,
.unwind_hdr = NULL,
.unwind_hdr_len = 0,
.sections = _stp_module_0_sections,
.num_sections = sizeof(_stp_module_0_sections)/sizeof(struct _stp_section),
.build_id_bits =
"\xd9\x1d\x7e\x1f\x5a\x79\xbc\xe0\x43\x34\x49\x69\x21\x59\x34\x1d\xbe\xe5\x8b\x33",
.build_id_len = 20,
.build_id_offset = 0xffffffff3fff8024,
.notes_sect = 0,
};
/****************************************************/
#vim runtime/sym.h
/****************************************************/
struct _stp_module {
const char* name;
const char* path; /* canonical path used for runtime matching. */
struct _stp_section *sections;
unsigned num_sections;
/* A pointer to the struct module. Note that we cannot */
/* trust this because as of 2.6.19, there are not yet */
/* any notifier hooks that will tell us when a module */
/* is unloading. */
unsigned long module; /* XXX: why not struct module * ? */
/* This is to undo .debug_frame relocation performed by elfutils, */
/* which is done during the translate phase when we encode the */
/* unwind data into the module. See adjustStartLoc() in unwind.c. */
unsigned long dwarf_module_base;
/* the stack unwind data for this module */
void *debug_frame;
void *eh_frame;
void *unwind_hdr;
uint32_t debug_frame_len;
uint32_t eh_frame_len;
uint32_t unwind_hdr_len;
unsigned long eh_frame_addr; /* Orig load address (offset) .eh_frame */
/* build-id information */
unsigned char *build_id_bits;
unsigned long build_id_offset;
unsigned long notes_sect;
int build_id_len;
};
/****************************************************/
However, I am trying to resolve this issue.
If you have any information related to this please share.
Best regards,
Naresh Kamboju
>
>>
>> Thanks,
>>
>> Mark
>>
>>
>
> Best regards,
> Naresh Kamboju
>