* Integer constant is too large for 'long' type @ 2009-11-05 8:40 naresh kamboju 2009-11-05 8:47 ` Mark Wielaard 0 siblings, 1 reply; 16+ messages in thread From: naresh kamboju @ 2009-11-05 8:40 UTC (permalink / raw) To: systemtap; +Cc: Frank Ch. Eigler Hi, I have notice following warning for the most of stp example files under testsuite directory. Warnings being treated as errors and coming out from the build. /*******************************************************************/ # 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) 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-g8de6eff Created temporary directory "/tmp/stapBF1Ti1" Searched '/usr/local/arm/cross/devel/share/systemtap/tapset/*.stp', found 56 Pass 1: parsed user script and 56 library script(s) in 270usr/20sys/340real ms. probe schedule@kernel/sched.c:4699 kernel reloc=.dynamic pc=0xc0310c84 probe schedule@kernel/sched.c:4699 kernel reloc=.dynamic pc=0xc0310c84 Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 0 global(s) in 400usr/20sys/509real ms. function recursion-analysis: max-nesting 0 non-recursive probe_1784 locks nothing probe_1785 locks nothing stap_dwarf_probe module[7] stap_dwarf_probe section[7] stap_dwarf_probe pp[59] dump_unwindsyms kernel index=0 base=0x0 Found build-id in kernel, length 20, end at 0x24 Found kernel _stext extra offset 0xc0008000 Pass 3: translated to C into "/tmp/stapBF1Ti1/five.c" in 570usr/20sys/601real ms. Running make -C "/lib/modules/2.6.29.4-kzm-arm11-g8de6eff/build" M="/tmp/stapBF1Ti1" ARCH="arm" "CROSS_COMPILE=/usr/local/arm/cross/devel/bin/arm-dev-" modules --no-print-directory CC [M] /tmp/stapBF1Ti1/five.o cc1: warnings being treated as errors 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 make[1]: *** [/tmp/stapBF1Ti1/five.o] Error 1 make: *** [_module_/tmp/stapBF1Ti1] Error 2 Pass 4: compiled C into "five.ko" in 3210usr/900sys/4604real ms. Pass 4: compilation failed. Try again with another '--vp 0001' option. Running rm -rf /tmp/stapBF1Ti1 /*******************************************************************/ SystemTap-1.0 elfutils-0.137 gcc version 4.3.3 glibc-2.9 Kernel 2.6.29 /*******************************************************************/ Please provide if you any information related to this. Best regards, Naresh Kamboju ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 8:40 Integer constant is too large for 'long' type naresh kamboju @ 2009-11-05 8:47 ` Mark Wielaard 2009-11-05 10:42 ` naresh kamboju 0 siblings, 1 reply; 16+ messages in thread From: Mark Wielaard @ 2009-11-05 8:47 UTC (permalink / raw) To: naresh kamboju; +Cc: systemtap, Frank Ch. Eigler 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. > 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? Thanks, Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 8:47 ` Mark Wielaard @ 2009-11-05 10:42 ` naresh kamboju 2009-11-05 14:56 ` naresh kamboju 2009-11-06 12:13 ` Mark Wielaard 0 siblings, 2 replies; 16+ messages in thread From: naresh kamboju @ 2009-11-05 10:42 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap, Frank Ch. Eigler 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. > > Thanks, > > Mark > > Best regards, Naresh Kamboju ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 10:42 ` naresh kamboju @ 2009-11-05 14:56 ` naresh kamboju 2009-11-05 15:25 ` Frank Ch. Eigler 2009-11-06 12:13 ` Mark Wielaard 1 sibling, 1 reply; 16+ messages in thread From: naresh kamboju @ 2009-11-05 14:56 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap, Frank Ch. Eigler 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 14:56 ` naresh kamboju @ 2009-11-05 15:25 ` Frank Ch. Eigler 2009-11-05 15:34 ` naresh kamboju 0 siblings, 1 reply; 16+ messages in thread From: Frank Ch. Eigler @ 2009-11-05 15:25 UTC (permalink / raw) To: naresh kamboju; +Cc: Mark Wielaard, systemtap Hi - On Thu, Nov 05, 2009 at 08:26:26PM +0530, naresh kamboju wrote: > [...] > # 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 > [...] > Session arch: arm release: 2.6.29.4-kzm-arm11-g2542246 > dump_unwindsyms kernel index=0 base=0x0 > Found build-id in kernel, length 20, end at 0x24 > [...] > .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, It seems as though the memory/section layout of the arm kernel is rather different from what we've seen. Can you send over some "readelf {-S,-l,-n} ..../vmlinux" output? - FChE ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 15:25 ` Frank Ch. Eigler @ 2009-11-05 15:34 ` naresh kamboju [not found] ` <20091105153606.GC21665@redhat.com> 0 siblings, 1 reply; 16+ messages in thread From: naresh kamboju @ 2009-11-05 15:34 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: Mark Wielaard, systemtap Hi Frank, On Thu, Nov 5, 2009 at 8:55 PM, Frank Ch. Eigler <fche@redhat.com> wrote: > Hi - > > On Thu, Nov 05, 2009 at 08:26:26PM +0530, naresh kamboju wrote: >> [...] >> # 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 >> [...] >> Session arch: arm release: 2.6.29.4-kzm-arm11-g2542246 >> dump_unwindsyms kernel index=0 base=0x0 >> Found build-id in kernel, length 20, end at 0x24 >> [...] >> .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, > > It seems as though the memory/section layout of the arm kernel is > rather different from what we've seen. ok. > Can you send over some > "readelf {-S,-l,-n} ..../vmlinux" output? I am not clear about above line. could give me in a detail steps, so that i can share build/results logs. Best regards, Naresh Kamboju > > - FChE > ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20091105153606.GC21665@redhat.com>]
[parent not found: <f5a7b3810911050748h1d4e82ft4d5af4a5b14d6d49@mail.gmail.com>]
* Re: Integer constant is too large for 'long' type [not found] ` <f5a7b3810911050748h1d4e82ft4d5af4a5b14d6d49@mail.gmail.com> @ 2009-11-05 15:54 ` Frank Ch. Eigler 2009-11-05 16:09 ` naresh kamboju 0 siblings, 1 reply; 16+ messages in thread From: Frank Ch. Eigler @ 2009-11-05 15:54 UTC (permalink / raw) To: naresh kamboju; +Cc: systemtap Hi - On Thu, Nov 05, 2009 at 09:18:28PM +0530, naresh kamboju wrote: > > readelf -S /lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build/vmlinux > > readelf -l /lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build/vmlinux > > readelf -n /lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build/vmlinux > I have attached logs and pasted here. > > /***********************************************************************/ > > readelf -S /lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build/vmlinux > /***********************************************************************/ > > There are 30 section headers, starting at offset 0x29deb0c: > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 0 0 0 > [ 1] .note.gnu.build-i NOTE 00000000 008000 000024 00 A 0 0 4 > [ 2] .text.head PROGBITS c0008000 010000 000240 00 AX 0 0 32 > [ 3] .init PROGBITS c0008240 010240 01ddc0 00 WAX 0 0 32 > [ 4] .text PROGBITS c0026000 02e000 3c3314 00 AX 0 0 32 > [ 5] .text.init PROGBITS c03e9314 3f1314 0000a0 00 AX 0 0 4 > [...] > > readelf -l /lib/modules/2.6.29.4-alp_nl-kzm-arm11-g2542246/build/vmlinux > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x008000 0x00000000 0x00000000 0x00024 0x00024 R 0x8000 > [...] > Section to Segment mapping: > Segment Sections... > 00 .note.gnu.build-id 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. My 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. 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. And that way the buildid bits get preserved. Can you check whether this is fixable in the arm kernel you are using? - FChE ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 15:54 ` Frank Ch. Eigler @ 2009-11-05 16:09 ` naresh kamboju 2009-11-16 15:45 ` naresh kamboju 0 siblings, 1 reply; 16+ messages in thread From: naresh kamboju @ 2009-11-05 16:09 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: systemtap Hi, On Thu, Nov 5, 2009 at 9:24 PM, Frank Ch. Eigler <fche@redhat.com> 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. My 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. And that way the buildid bits get > preserved. Can you check whether this is fixable in the arm kernel > you are using? I'll check at my end with arm Kernel. Thank you very much. Best regards Naresh Kamboju > > - FChE > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 16:09 ` naresh kamboju @ 2009-11-16 15:45 ` naresh kamboju 2009-11-16 18:16 ` Eugeniy Meshcheryakov ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: naresh kamboju @ 2009-11-16 15:45 UTC (permalink / raw) To: systemtap Cc: Frank Ch. Eigler, Dave Brolley, David Smith, Masami Hiramatsu, eugen Hi, On Thu, Nov 5, 2009 at 9:39 PM, naresh kamboju <naresh.kernel@gmail.com> wrote: > Hi, > > On Thu, Nov 5, 2009 at 9:24 PM, Frank Ch. Eigler <fche@redhat.com> 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. My 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. And that way the buildid bits get >> preserved. Can 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 = 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 “.build_id_offset = 0xffffffff3fff8024” is filled with larger value in to “unsigned long build_id_offset;” From ".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 >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-16 15:45 ` naresh kamboju @ 2009-11-16 18:16 ` Eugeniy Meshcheryakov 2009-11-16 18:24 ` Eugeniy Meshcheryakov 2009-11-17 20:02 ` Frank Ch. Eigler 2 siblings, 0 replies; 16+ messages in thread From: Eugeniy Meshcheryakov @ 2009-11-16 18:16 UTC (permalink / raw) To: naresh kamboju Cc: systemtap, Frank Ch. Eigler, Dave Brolley, David Smith, Masami Hiramatsu [-- Attachment #1: Type: text/plain, Size: 1969 bytes --] Hello, 16 листопада 2009 о 21:14 +0530 naresh kamboju написав(-ла): > 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 This patch was needed for kernels with CONFIG_RELOCATABLE set. > > translate.cxx: > c->output << ".build_id_offset = 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 “.build_id_offset = > 0xffffffff3fff8024” is filled with larger value in to “unsigned long > build_id_offset;” Does casting everything to unsigned long work? Or does it give incorrect result? > > From ".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 > >> [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-16 15:45 ` naresh kamboju 2009-11-16 18:16 ` Eugeniy Meshcheryakov @ 2009-11-16 18:24 ` Eugeniy Meshcheryakov 2009-11-26 7:04 ` naresh kamboju 2009-11-17 20:02 ` Frank Ch. Eigler 2 siblings, 1 reply; 16+ messages in thread From: Eugeniy Meshcheryakov @ 2009-11-16 18:24 UTC (permalink / raw) To: naresh kamboju Cc: systemtap, Frank Ch. Eigler, Dave Brolley, David Smith, Masami Hiramatsu [-- Attachment #1: Type: text/plain, Size: 322 bytes --] 16 листопада 2009 о 21:14 +0530 naresh kamboju написав(-ла): > 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? [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-16 18:24 ` Eugeniy Meshcheryakov @ 2009-11-26 7:04 ` naresh kamboju 0 siblings, 0 replies; 16+ messages in thread From: naresh kamboju @ 2009-11-26 7:04 UTC (permalink / raw) To: Eugeniy Meshcheryakov Cc: systemtap, Frank Ch. Eigler, Dave Brolley, David Smith, Masami Hiramatsu 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 =================================================================== --- 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 == "kernel") +#if 0 c->output << ".build_id_offset = 0x" << hex << build_id_vaddr - (base + extra_offset) << dec << ",\n"; +#else + c->output << ".build_id_offset = 0x" << hex << build_id_vaddr + << dec << ",\n"; +#endif else c->output << ".build_id_offset = 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 <eugen@debian.org> wrote: > 16 листопада 2009 о 21:14 +0530 naresh kamboju написав(-ла): >> 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 > =cxSs > -----END PGP SIGNATURE----- > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-16 15:45 ` naresh kamboju 2009-11-16 18:16 ` Eugeniy Meshcheryakov 2009-11-16 18:24 ` Eugeniy Meshcheryakov @ 2009-11-17 20:02 ` Frank Ch. Eigler 2009-11-18 14:51 ` naresh kamboju 2 siblings, 1 reply; 16+ messages in thread From: Frank Ch. Eigler @ 2009-11-17 20:02 UTC (permalink / raw) To: naresh kamboju Cc: systemtap, Dave Brolley, David Smith, Masami Hiramatsu, eugen Hi - On Mon, Nov 16, 2009 at 09:14:52PM +0530, naresh kamboju wrote: > [...] > In the above line, extra_offset datatype is "long long int" but > ".build_id_offset is "unsigned long" only. [...] That's because it presumes that the buildid note section will be located somewhat after .text. In the case of your arm kernel build, that's not the case. > However, I have [reverted] this patch and able to resolve the build > issue on ARM. 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. - FChE ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-17 20:02 ` Frank Ch. Eigler @ 2009-11-18 14:51 ` naresh kamboju 0 siblings, 0 replies; 16+ messages in thread From: naresh kamboju @ 2009-11-18 14:51 UTC (permalink / raw) To: Frank Ch. Eigler Cc: systemtap, Dave Brolley, David Smith, Masami Hiramatsu, eugen 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 =================================================================== --- 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 == "kernel") +#if 0 c->output << ".build_id_offset = 0x" << hex << build_id_vaddr - (base + extra_offset) << dec << ",\n"; +#else + c->output << ".build_id_offset = 0x" << hex << build_id_vaddr + << dec << ",\n"; +#endif else c->output << ".build_id_offset = 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 Please provide your comments. Best regards Naresh Kamboju ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-05 10:42 ` naresh kamboju 2009-11-05 14:56 ` naresh kamboju @ 2009-11-06 12:13 ` Mark Wielaard 2009-11-06 14:36 ` naresh kamboju 1 sibling, 1 reply; 16+ messages in thread From: Mark Wielaard @ 2009-11-06 12:13 UTC (permalink / raw) To: naresh kamboju; +Cc: systemtap, Frank Ch. Eigler On Thu, 2009-11-05 at 16:12 +0530, naresh kamboju wrote: > On Thu, Nov 5, 2009 at 2:16 PM, Mark Wielaard <mjw@redhat.com> wrote: > > 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 . I quickly looked at that bug, I think that isn't related to the problem you are seeing (with current systemtap/elfutils it fails differently). In general the latest elfutils release (currently 0.143) is preferred (later versions are also required for some of the newer features of systemtap). Cheers, Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Integer constant is too large for 'long' type 2009-11-06 12:13 ` Mark Wielaard @ 2009-11-06 14:36 ` naresh kamboju 0 siblings, 0 replies; 16+ messages in thread From: naresh kamboju @ 2009-11-06 14:36 UTC (permalink / raw) To: Mark Wielaard; +Cc: systemtap, Frank Ch. Eigler Hi Mark, On Fri, Nov 6, 2009 at 5:43 PM, Mark Wielaard <mjw@redhat.com> wrote: > On Thu, 2009-11-05 at 16:12 +0530, naresh kamboju wrote: >> >> 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 . > > I quickly looked at that bug, I think that isn't related to the problem > you are seeing (with current systemtap/elfutils it fails differently). > In general the latest elfutils release (currently 0.143) is preferred > (later versions are also required for some of the newer features of > systemtap). I have build latest systemtap/elfutils SystemTap translator/driver (version 1.0/0.143 non-git sources) found following example build issues. Error: 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. discussed same issue with Frank, I think you have gone through following discussion. http://sourceware.org/ml/systemtap/2009-q4/msg00418.html http://sourceware.org/ml/systemtap/2009-q4/msg00419.html http://sourceware.org/ml/systemtap/2009-q4/msg00420.html http://sourceware.org/ml/systemtap/2009-q4/msg00436.html http://sourceware.org/ml/systemtap/2009-q4/msg00437.html http://sourceware.org/ml/systemtap/2009-q4/msg00438.html http://sourceware.org/ml/systemtap/2009-q4/msg00439.html http://sourceware.org/ml/systemtap/2009-q4/msg00441.html if you have any inputs regarding this issues please provide. Best regards, Naresh Kamboju > > Cheers, > > Mark > > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-11-26 7:04 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-05 8:40 Integer constant is too large for 'long' type naresh kamboju 2009-11-05 8:47 ` Mark Wielaard 2009-11-05 10:42 ` naresh kamboju 2009-11-05 14:56 ` naresh kamboju 2009-11-05 15:25 ` Frank Ch. Eigler 2009-11-05 15:34 ` naresh kamboju [not found] ` <20091105153606.GC21665@redhat.com> [not found] ` <f5a7b3810911050748h1d4e82ft4d5af4a5b14d6d49@mail.gmail.com> 2009-11-05 15:54 ` Frank Ch. Eigler 2009-11-05 16:09 ` naresh kamboju 2009-11-16 15:45 ` naresh kamboju 2009-11-16 18:16 ` Eugeniy Meshcheryakov 2009-11-16 18:24 ` Eugeniy Meshcheryakov 2009-11-26 7:04 ` naresh kamboju 2009-11-17 20:02 ` Frank Ch. Eigler 2009-11-18 14:51 ` naresh kamboju 2009-11-06 12:13 ` Mark Wielaard 2009-11-06 14:36 ` naresh kamboju
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).