On 07/28/2015 03:04 PM, Don Maghrak wrote:
AFAIK, symtabapi is not resolving statements when used directly. It does
get the function symbols
based on output Jim sent earlier.
Jim ran our bfd resolver and that resolves functions and statements.
Does this suggest SymtabAPI has an issue with state
From Rashawn Knapp at Intel: Enable building Dyninst with ICC
From John Mellor-Crummey at Rice: Fix a fencepost error in SymtabAPI's
DWARF parsing
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.ed
On 07/28/2015 01:47 PM, Jim Galarowicz wrote:
Hi Bill, all,
I cancelled my original post - too large. Resending a shortened version..
I sent mail to a NASA representative about the elf.h EM_ architecture
enumerated value.
The elf.h files that I've been able to locate only go up to the
enumer
This commit updates DyninstAPI.doc to include the new loop interfaces
and explanations for
irreducible loops
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Hi Bill, all,
I cancelled my original post - too large. Resending a shortened version..
I sent mail to a NASA representative about the elf.h EM_ architecture
enumerated value.
The elf.h files that I've been able to locate only go up to the
enumerated value of 95.
The Intel MIC application
On 07/28/2015 11:31 AM, Jim Galarowicz wrote:
Hi Bill,
I've built dyninst from the latest git bits for dyninst and then changed
our source to get around the loop head API issue.
When I run using the new version of dyninst, I'm still getting the
architecture assert shown below.
Is there anything
Hi Bill,
I've built dyninst from the latest git bits for dyninst and then changed
our source to get around the loop head API issue.
When I run using the new version of dyninst, I'm still getting the
architecture assert shown below.
Is there anything I can try to get around this issue?
Jim G
You might be hitting a common problem that manifests when a system has
installs of both the orignal libelf (libelf.so.0) and the RedHat version
of libelf (libelf.so.1). If Dyninst is built against the header files of
one libelf and the library of the other, that can cause it to fail to
parse
On 07/27/2015 05:50 PM, Ioannis Konstadelias wrote:
Well,
maybe then I have something wrong in my mutator source. Here is the
whole directory. I use the version with the commit that fixes the boost
problem.
Your mutator also works fine for me locally, and the not-yet-committed
changes I have a
It is more complicated than that. For a natural loop, it only has one
entry, which is also called the head because the entry dominates all
blocks of the loop. However, for an irreducible loop, it can have
multiple entries and it is possible that none of the entries dominates
the other blocks in the
Hi Xiaozhu,
Is the first entry in the vector e the loop head?
BPatch_Vector entries;
loop->getLoopEntries(entries);
BPatch_basicBlock* head = entries[0];
if (head == NULL)
{
continue;
Xiaozhu,
Do we have an updated manual entry for the new getLoopEntries?
--bart
On 7/28/2015 10:37 AM, Xiaozhu Meng wrote:
Hi Jim,
The old getLoopHead() method has been replaced by the following new
interface to appropriately represent irreducible loops:
int BPatch_basicBlockLoop::getLoopEnt
Hi Jim,
The old getLoopHead() method has been replaced by the following new
interface to appropriately represent irreducible loops:
int BPatch_basicBlockLoop::getLoopEntries(BPatch_Vector &e);
The new interface returns the number of entry blocks of this loop and
the entries blocks are returned a
Hi all,
I've downloaded the git source version of dyninst and built it on NASA's
pfe machine and my laptop in an attempt to run it on Intel MIC
binaries. The 8.2.1 asserts in switches related to the architecture type.
However, I ran into a compile error with our loop code:
[ 16%] Buildin
14 matches
Mail list logo
