This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]