From: "Frank Ch. Eigler" <fche@redhat.com>
To: naresh kamboju <naresh.kernel@gmail.com>
Cc: systemtap@sources.redhat.com
Subject: Re: Integer constant is too large for 'long' type
Date: Thu, 05 Nov 2009 15:54:00 -0000 [thread overview]
Message-ID: <20091105155425.GD21665@redhat.com> (raw)
In-Reply-To: <f5a7b3810911050748h1d4e82ft4d5af4a5b14d6d49@mail.gmail.com>
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
next prev parent reply other threads:[~2009-11-05 15:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 8:40 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091105155425.GD21665@redhat.com \
--to=fche@redhat.com \
--cc=naresh.kernel@gmail.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).