From: "Mao, Bibo" <bibo.mao@intel.com>
To: "Roland McGrath" <roland@redhat.com>,
"Frank Ch. Eigler" <fche@redhat.com>
Cc: <systemtap@sources.redhat.com>
Subject: RE: inconsistent module relocation in elfutils
Date: Tue, 08 Nov 2005 09:42:00 -0000 [thread overview]
Message-ID: <9FBCE015AF479F46B3B410499F3AE05B08979B@pdsmsx405> (raw)
[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]
>-----Original Message-----
>From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
>On Behalf Of Roland McGrath
>Sent: 2005年11月5日 4:37
>To: Frank Ch. Eigler
>Cc: systemtap@sources.redhat.com
>Subject: Re: inconsistent module relocation in elfutils
>
>> Specifically, with some kernel versions (e.g. 2.6.13-1.1532_FC4) I
>> find that the GElf_Shdr sh_addr fields of .text-like sections are
>> correctly relocated, and for other kernel versions (2.6.9-22.EL), that
>> field is left at zero. Can you suggest an explanation or workaround?
>
>You should not have any particular expectations about section headers in
>ET_REL modules. The fact that you see an sh_addr you can use there is more
>an artifact of the implementation than something you should be relying on.
>When using the style of module callback now in use (-k), the only sections
>whose addresses are noted are those needed to relocate the debug info.
>
>> One can put a breakpoint at tapsets.cxx:1673 and look at variable "*shdr".
>
>I don't think that code is the right way to do that. Instead use
>dwfl_module_relocate_address and dwfl_module_relocation_info to get the
>section name.
In IA64 platform, we test elfutils-0.116 by test case ./dwflmodtest -k command, we find that there will be "Unsupported relocation type". In IA64 platform, it use default default_reloc_simple_type function, and this function return ELF_T_NUM value. It will be regarded as unknown relocated type.
So I think in IA64 platform there should be some function like i386_reloc_simple_type, x86_64_reloc_simple_type. Here in the attachment it defines relocation type for IA64. This patch only defines little endian type, also it need define big endian type.
[-- Attachment #2: patch_elfutils_ia64_relocate_type --]
[-- Type: application/octet-stream, Size: 2318 bytes --]
diff -urN elfutils-0.115.org/libebl/ia64_init.c elfutils-0.115/libebl/ia64_init.c
--- elfutils-0.115.org/libebl/ia64_init.c 2005-11-01 03:10:41.000000000 +0800
+++ elfutils-0.115/libebl/ia64_init.c 2005-11-01 03:11:57.000000000 +0800
@@ -34,6 +34,7 @@
eh->name = "Intel IA-64";
eh->reloc_type_name = ia64_reloc_type_name;
eh->reloc_type_check = ia64_reloc_type_check;
+ eh->reloc_simple_type = ia64_reloc_simple_type;
eh->segment_type_name = ia64_segment_type_name;
eh->dynamic_tag_name = ia64_dynamic_tag_name;
eh->copy_reloc_p = ia64_copy_reloc_p;
diff -urN elfutils-0.115.org/libebl/ia64_symbol.c elfutils-0.115/libebl/ia64_symbol.c
--- elfutils-0.115.org/libebl/ia64_symbol.c 2005-11-01 03:10:41.000000000 +0800
+++ elfutils-0.115/libebl/ia64_symbol.c 2005-11-01 03:12:08.000000000 +0800
@@ -131,6 +131,42 @@
}
+/* Check for the simple reloc types. */
+Elf_Type
+ia64_reloc_simple_type (Elf *elf __attribute__ ((unused)), int type)
+{
+ switch (type)
+ {
+ case R_IA64_SECREL64LSB:
+ case R_IA64_SEGREL64LSB:
+ case R_IA64_DIR64LSB:
+ case R_IA64_REL64LSB:
+ case R_IA64_GPREL64LSB:
+ case R_IA64_FPTR64LSB:
+ case R_IA64_PCREL64LSB:
+ case R_IA64_LTOFF_FPTR64LSB:
+ case R_IA64_LTV64LSB:
+ case R_IA64_DTPREL64LSB:
+ return ELF_T_XWORD;
+
+ case R_IA64_SECREL32LSB:
+ case R_IA64_SEGREL32LSB:
+ case R_IA64_DIR32LSB:
+ case R_IA64_REL32LSB:
+ case R_IA64_GPREL32LSB:
+ case R_IA64_FPTR32LSB:
+ case R_IA64_PCREL32LSB:
+ case R_IA64_LTOFF_FPTR32LSB:
+ case R_IA64_LTV32LSB:
+ case R_IA64_DTPREL32LSB:
+ return ELF_T_WORD;
+
+ default:
+ return ELF_T_NUM;
+ }
+}
+
+
/* Check for correct relocation type. */
bool
ia64_reloc_type_check (int type)
diff -urN elfutils-0.115.org/libebl/libebl_ia64.h elfutils-0.115/libebl/libebl_ia64.h
--- elfutils-0.115.org/libebl/libebl_ia64.h 2005-11-01 03:10:41.000000000 +0800
+++ elfutils-0.115/libebl/libebl_ia64.h 2005-11-01 03:12:26.000000000 +0800
@@ -31,6 +31,9 @@
/* Check relocation type. */
extern bool ia64_reloc_type_check (int type);
+/* Check for simple reloc types */
+extern Elf_Type ia64_reloc_simple_type(Elf *elf, int type);
+
/* Name of segment type. */
extern const char *ia64_segment_type_name (int segment, char *buf, size_t len);
next reply other threads:[~2005-11-08 9:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 9:42 Mao, Bibo [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-04 20:08 Frank Ch. Eigler
2005-11-04 20:37 ` Roland McGrath
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=9FBCE015AF479F46B3B410499F3AE05B08979B@pdsmsx405 \
--to=bibo.mao@intel.com \
--cc=fche@redhat.com \
--cc=roland@redhat.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).