public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
To: systemtap@sourceware.org
Cc: hemant@linux.vnet.ibm.com, atrajeev@linux.vnet.ibm.com,
	mjw@redhat.com,        fche@redhat.com, dsmith@redhat.com,
	naveen.n.rao@linux.vnet.ibm.com,
	       Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Subject: [PATCH v3 2/2] ppc64le: Fix LEP usage for probing
Date: Tue, 23 Aug 2016 11:24:00 -0000	[thread overview]
Message-ID: <1471951468-2567-2-git-send-email-ravi.bangoria@linux.vnet.ibm.com> (raw)
In-Reply-To: <1471951468-2567-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com>

PPC64 ELF ABI v2 has a Global Entry Point and a Local Entry Point for
the functions. Debuginfo of ELF contains GEP which is same as entrypc
while symbol table contains GEP and offset, from which we can calculate
LEP. LEP is used to call function within single CU, when TOC pointer
update is not required. Placing a probe on LEP catches call from both
the GEP and the LEP but, by default, systemtap probes on GEP.

Commit b4c6a4b1cd00 ("Prioritize symbol table lookup for ppc64le") solve
this issue by storing LEP in symbol table and prioritizing symbol table
over debuginfo for ppc64le.

But there are few regression effect of this patch. Couple of examples
are given below.

1. If target program is compiled without optimization and user is
interested in function parameter, systemtap should probe after function
prologue. But above patch forces probe on LEP and which result in garbage
value of function parameter will get recorded.

  $ make verbose=1 installcheck RUNTESTFLAGS='at_var.exp -v --debug'
    ...
    # of expected passes        1
    # of unexpected failures    1

2. Probe on shared library function with parameter is failing at Pass 2.

  $ make verbose=1 installcheck RUNTESTFLAGS='exelib.exp -v --debug'
    ...
    # of expected passes        10
    # of unexpected failures    64

3. When symbol_name with offset is used to register kprobe, kernel itself
will find LEP and adds offset to it. Systemtap using LEP to find offset
is resulting in offset being added two times.
  GEP + lep_offset (by systemtap) + lep_offset (by kernel)

This can be solved by calculating LEP only at a time of adding a probe.
That will make effect of LEP local to that area and won't have any
regression effect.

After applying patch:

  $ make verbose=1 installcheck RUNTESTFLAGS='at_var.exp -v --debug'
    ...
    # of expected passes        2

  $ make verbose=1 installcheck RUNTESTFLAGS='exelib.exp -v --debug'
    ...
    # of expected passes        74

Fixes: Commit b4c6a4b1cd00 ("Prioritize symbol table lookup for ppc64le")
Reported-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[ Reported about issue with shared library ]
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
---
Changes in v3:
  - No changes

 tapsets.cxx | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/tapsets.cxx b/tapsets.cxx
index 997cc88..bf1bcc0 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
@@ -1391,6 +1391,59 @@ string path_remove_sysroot(const systemtap_session& sess, const string& path)
   return retval;
 }
 
+/*
+ * Convert 'Global Entry Point' to 'Local Entry Point'.
+ *
+ * if @gep contains next address after prologue, don't change it.
+ *
+ * For ELF ABI v2 on PPC64 LE, we need to adjust sym.st_value corresponding
+ * to the bits of sym.st_other. These bits will tell us what's the offset
+ * of the local entry point from the global entry point.
+ *
+ * st_other field is currently only used with ABIv2 on ppc64
+ */
+static Dwarf_Addr
+get_lep(dwarf_query *q, Dwarf_Addr gep)
+{
+  Dwarf_Addr bias;
+  Dwfl_Module *mod = q->dw.module;
+  Elf* elf = (dwarf_getelf (dwfl_module_getdwarf (mod, &bias))
+             ?: dwfl_module_getelf (mod, &bias));
+
+  GElf_Ehdr ehdr_mem;
+  GElf_Ehdr* em = gelf_getehdr (elf, &ehdr_mem);
+  if (em == NULL)
+    throw SEMANTIC_ERROR (_("Couldn't get elf header"));
+
+  if (!(em->e_machine == EM_PPC64) || !((em->e_flags & EF_PPC64_ABI) == 2))
+    return gep;
+
+  int syments = dwfl_module_getsymtab(mod);
+  for (int i = 1; i < syments; ++i)
+    {
+      GElf_Sym sym;
+      GElf_Word section;
+      GElf_Addr addr;
+
+#if _ELFUTILS_PREREQ (0, 158)
+      dwfl_module_getsym_info (mod, i, &sym, &addr, &section, NULL, NULL);
+#else
+      dwfl_module_getsym (mod, i, &sym, &section);
+      addr = sym.st_value;
+#endif
+
+      /*
+       * Symbol table contains module_bias + offset. Substract module_bias
+       * to compare offset with gep.
+       */
+      if ((addr - bias) == gep && (GELF_ST_TYPE(sym.st_info) == STT_FUNC)
+          && sym.st_other)
+        return gep + PPC64_LOCAL_ENTRY_OFFSET(sym.st_other);
+    }
+
+  return gep;
+}
+
 void
 dwarf_query::add_probe_point(interned_string dw_funcname,
 			     interned_string filename,
@@ -1399,12 +1452,14 @@ dwarf_query::add_probe_point(interned_string dw_funcname,
 			     Dwarf_Addr addr)
 {
   interned_string reloc_section; // base section for relocation purposes
+  Dwarf_Addr orig_addr = addr;
   Dwarf_Addr reloc_addr; // relocated
   interned_string module = dw.module_name; // "kernel" or other
   interned_string funcname = dw_funcname;
 
   assert (! has_absolute); // already handled in dwarf_builder::build()
 
+  addr = get_lep(this, addr);
   reloc_addr = dw.relocate_address(addr, reloc_section);
 
   // If we originally used the linkage name, then let's call it that way
@@ -1470,7 +1525,10 @@ dwarf_query::add_probe_point(interned_string dw_funcname,
 
 	      symbol_table *sym_table = mi->sym_table;
 	      func_info *symbol = sym_table->get_func_containing_address(addr);
-	      Dwarf_Addr offset = addr - symbol->addr;
+
+	      // Do not use LEP to find offset here. When 'symbol_name'
+	      // is used to register probe, kernel itself will find LEP.
+	      Dwarf_Addr offset = orig_addr - symbol->addr;
 	      results.push_back (new dwarf_derived_probe(funcname, filename,
 							 line, module,
 							 reloc_section, addr,
-- 
1.8.3.1


  reply	other threads:[~2016-08-23 11:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 11:24 [PATCH v3 1/2] ppc64le: Store correct function entry address in symbol_table Ravi Bangoria
2016-08-23 11:24 ` Ravi Bangoria [this message]
2016-08-25 14:02 ` Frank Ch. Eigler

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=1471951468-2567-2-git-send-email-ravi.bangoria@linux.vnet.ibm.com \
    --to=ravi.bangoria@linux.vnet.ibm.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=dsmith@redhat.com \
    --cc=fche@redhat.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=mjw@redhat.com \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /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).