public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
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);
 

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