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

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

[mjw at redhat dot com]

This might be because of the somewhat peculiar way the exelib.exp test prelinks
the library to an arbitrary address (but doesn't prelink the executable using
it), but the result is a valid executable/sharedlib.

    if {$libprelink == "yes"} {
         set prelink_bin "/usr/sbin/prelink"
         set addr "-r 0x6400000"
         set prelink_cmd [concat $prelink_bin -vfNR $addr $testso]
         send_log "Executing: $prelink_cmd\n"
         catch {eval exec $prelink_cmd} result
         verbose -log "result is $result"
    }


uprobes install fails with:
uprobe failed uprobesgcc-O3de[3865]
'process("/home/mark/src/systemtap/testsuite/libuprobeslibgcc-O3default-prelink-debug.so").function("lib_func@/home/mark/src/systemtap/testsuite/systemtap.exelib/uprobes_lib.c:11")'
addr 00007f65c263a590 rc -22

-- 
           Summary: uprobes fail to insert on prelinked library
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


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.

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

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2009-06-12 21:24 -------
-22 = -EINVAL, which typically means that the address to be probed doesn't lie
in an executable vm area.

-- 


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.

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

[mjw at redhat dot com]

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

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

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-06-18 16:14 -------
So that was almost the correct fix.

The reason this adjustment is necessary is because the addresses we get are from
libdw so we do need to adjust for the bias returned from dwfl_getdwarf (). And
what we call module_bias is that bias.

To be correct we need to adjust before feeding the address to dwfl, which is
what this commit does:

commit d2309c6c3fb97cc0c8931b59e33fe18820b63c5d
Author: Mark Wielaard <mjw@redhat.com>
Date:   Thu Jun 18 17:54:15 2009 +0200

    PR10273 Correctly adjust libdw address for dwfl dwarf bias.
    
    * dwflpp.cxx (relocate_address): Adjust reloc_addr at start, not afterwards.

diff --git a/dwflpp.cxx b/dwflpp.cxx
index e01c697..61627e1 100644
--- a/dwflpp.cxx
+++ b/dwflpp.cxx
@@ -2341,11 +2341,13 @@ dwflpp::get_blacklist_section(Dwarf_Addr addr)
 
 
 Dwarf_Addr
-dwflpp::relocate_address(Dwarf_Addr addr,
+dwflpp::relocate_address(Dwarf_Addr dw_addr,
                          string& reloc_section,
                          string& blacklist_section)
 {
-  Dwarf_Addr reloc_addr = addr;
+  // PR10273
+  // libdw address, so adjust for bias gotten from dwfl_module_getdwarf
+  Dwarf_Addr reloc_addr = dw_addr + module_bias;
   if (!module)
     {
       assert(module_name == TOK_KERNEL);
@@ -2364,14 +2366,13 @@ dwflpp::relocate_address(Dwarf_Addr addr,
 
       if (reloc_section == "" && dwfl_module_relocations (module) == 1)
         {
-          blacklist_section = get_blacklist_section(addr);
+          blacklist_section = get_blacklist_section(dw_addr);
           reloc_section = ".dynamic";
-          reloc_addr += module_bias;  // PR10273
         }
     }
   else
     {
-      blacklist_section = get_blacklist_section(addr);
+      blacklist_section = get_blacklist_section(dw_addr);
       reloc_section = ".absolute";
     }
   return reloc_addr;


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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.