inconsistent module relocation in elfutils

[Mao, Bibo]

>-----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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_elfutils_ia64_relocate_type
Type: application/octet-stream
Size: 2318 bytes
Desc: patch_elfutils_ia64_relocate_type
URL: <http://sourceware.org/pipermail/systemtap/attachments/20051108/4c783628/attachment.obj>