This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug uprobes/10273] uprobes fail to insert on prelinked library


------- Additional Comments From mjw at redhat dot com  2009-06-17 14:15 -------
So (part) of the problem is the dwflpp.cxx relocate_address function:

Dwarf_Addr
dwflpp::relocate_address(Dwarf_Addr addr,
                         string& reloc_section,
                         string& blacklist_section)
{
  Dwarf_Addr reloc_addr = addr;
  if (!module)
    {
      assert(module_name == TOK_KERNEL);
      reloc_section = "";
      blacklist_section = "";
    }
  else if (dwfl_module_relocations (module) > 0)
    {
      // This is a relocatable module; libdwfl already knows its
      // sections, so we can relativize addr.
      int idx = dwfl_module_relocate_address (module, &reloc_addr);
      const char* r_s = dwfl_module_relocation_info (module, idx, NULL);
      if (r_s)
        reloc_section = r_s;
      blacklist_section = reloc_section;

      if (reloc_section == "" && dwfl_module_relocations (module) == 1)
        {
          blacklist_section = get_blacklist_section(addr);
          reloc_section = ".dynamic";
          reloc_addr = addr; // <=== HERE! Problem!
        }
    }
  else
    {
      blacklist_section = get_blacklist_section(addr);
      reloc_section = ".absolute";
    }
  return reloc_addr;
}

Note how if the address is from an .dynamic section we just return the address
as is without relocation (in the case of the test that is the function probe
address, the prologue_end).

The address is already absolute relative to the module (shared library) load
address minus the dwfl module bias.

So the patch that seems to fix this issue seems to be:

--- a/dwflpp.cxx
+++ b/dwflpp.cxx
@@ -2366,7 +2366,7 @@ dwflpp::relocate_address(Dwarf_Addr addr,
         {
           blacklist_section = get_blacklist_section(addr);
           reloc_section = ".dynamic";
-          reloc_addr = addr;
+          reloc_addr += module_bias;
         }
     }
   else

I have added that for now since it resolves the test cases issues we were
seeing, but I leave this bug report open till I fully understand why we have to
add the module_bias explicitly ourselves in this case

BTW. The reason it worked in the non-[p]relinked shared library case was because
module_start == module_bias in that case. While in the [p]relinked case it seems
dwfl always loads the module at the relinked address plus module bias. This also
explains why the change doesn't affect the original case because
dwfl_module_relocate_address substracts the module start address so adding the
bias back just reverses that operation in that case.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10273

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]