[DynInst_API:] [dyninst/dyninst] c3a140: After carefully comparing the parsing output of ru...


Date: Thu, 23 Aug 2018 08:12:32 -0700
From: Xiaozhu Meng <xmeng@xxxxxxxxxxx>
Subject: [DynInst_API:] [dyninst/dyninst] c3a140: After carefully comparing the parsing output of ru...
  Branch: refs/heads/new-parallel-parsing
  Home:   https://github.com/dyninst/dyninst
  Commit: c3a1400592a7aad6136b4f0662d0f8b7971474a7
      https://github.com/dyninst/dyninst/commit/c3a1400592a7aad6136b4f0662d0f8b7971474a7
  Author: Xiaozhu Meng <xmeng@xxxxxxxxxxx>
  Date:   2018-08-23 (Thu, 23 Aug 2018)

  Changed paths:
    M dataflowAPI/src/AbslocInterface.C
    M dataflowAPI/src/slicing.C
    M parseAPI/h/CFG.h
    M parseAPI/h/CFGFactory.h
    M parseAPI/src/BoundFactCalculator.C
    M parseAPI/src/CFGFactory.C
    M parseAPI/src/IndirectAnalyzer.C
    M parseAPI/src/IndirectAnalyzer.h
    M parseAPI/src/JumpTableIndexPred.C
    M parseAPI/src/Parser.C
    M parseAPI/src/Parser.h

  Log Message:
  -----------
  After carefully comparing the parsing output of runs with different
numbers of threads and examining the debug logs, there are many issues:

1. During parallel parsing, we split a block when the block has an
incoming edge within the block range. However, we do not split a block
if the edge jumps into the block range of a block from another function.
So, at finalizing time, we should split such overlapped blocks. An
alternative here is to split a block from another function at parsing
time, which requires a global range lookup and will cause mutual
exclusion in parallel parsing.

2. The jump table analysis is not working properly for many reasons...
2.A. When generating Absloc, we should not bind SP or FP when stack
     analysis is not enabled. Otherwise, the default value for binding
     SP and FP is 0, causing wrong abstract locations.

2.B. Slicing should no longer use SingleContextOrInterproc because
     SingleContextOrInterproc relies on a complete function boundary,
     which is not the case when the jump table analysis invokes slicing.
     Slicing should just traverse all source edges and let the slicing
     predicate determine whether or not to follow interprocedural edges.

2.C. Slicing should treat tail calls as function calls rather than normal jumps.

2.D The jump table analysis needs to traverse the CFG from function entry.
    For blocks shared by multiple functions, the outgoing edges may be changed
    during the jump table analysis. So, we should make a copy of the outgoing
    edges before traversing and the copy operation should have locking. Here,
    an alternative is to lock the block during traversing, but I feel this
    alternative may cause too much lock contention.

2.E We should ignore CATCH edges because they do not represent real
    control flow.

2.F We should distinguish zero extend and sign extend memory reads.



      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.
[← Prev in Thread] Current Thread [Next in Thread→]
  • [DynInst_API:] [dyninst/dyninst] c3a140: After carefully comparing the parsing output of ru..., Xiaozhu Meng <=