This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-238-g432f054)
- From: Roland McGrath <roland at redhat dot com>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: systemtap at sourceware dot org, fche at sourceware dot org
- Date: Wed, 8 Apr 2009 05:40:44 -0700 (PDT)
- Subject: Re: PR10000: emit _stp_relocate* calculations correctly for kernel/module global $data (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9-238-g432f054)
- References: <20090327155519.19560.qmail@sourceware.org> <1239187983.3146.55.camel@fedora.wildebeest.org>
> Allowing STT_OBJECTS also allowed in some odd creatures that don't seem
> to be real symbols. In my case in libc.so the following things got
> really malformed (negative) addresses leading to the infamous "error:
> integer constant is too large for ?long? type" in stap-symbols.h:
>
> { 0xffffffffffeda000, "__evoke_link_warning_fdetach" },
> { 0xffffffffffeda040, "__evoke_link_warning_getwd" },
I don't know where those crazy values come from. These symbols are local,
have actual value of zero, and are in non-SHF_ALLOC sections.
> If there is a better way to recognize these (they have a "normal"
> st_shndx as far as I can tell) please let me know.
Any symbol in a non-SHF_ALLOC section should be of no concern to you.
All sorts of symbols in non-allocated sections (e.g. in .debug_*
sections) might sometimes be in an unstripped .symtab, not just these
(which are in link-time magic sections).
Thanks,
Roland