Integer constant is too large for 'long' type

Integer constant is too large for 'long' type

[naresh kamboju]

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

Re: Integer constant is too large for 'long' type

[Mark Wielaard]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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
>

Re: Integer constant is too large for 'long' type

[Frank Ch. Eigler]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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
>

Re: Integer constant is too large for 'long' type

[Frank Ch. Eigler]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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
>

Re: Integer constant is too large for 'long' type

[Mark Wielaard]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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
>
>

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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
>>

Re: Integer constant is too large for 'long' type

[Eugeniy Meshcheryakov]

[-- 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 --]

Re: Integer constant is too large for 'long' type

[Eugeniy Meshcheryakov]

[-- 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 --]

Re: Integer constant is too large for 'long' type

[Frank Ch. Eigler]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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

Re: Integer constant is too large for 'long' type

[naresh kamboju]

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-----
>
>