Re: [DynInst_API:] API-breaking changes for upcoming Dyninst 11.0 release


Date: Tue, 27 Oct 2020 13:16:28 -0500
From: "Mark W. Krentel" <krentel@xxxxxxxx>
Subject: Re: [DynInst_API:] API-breaking changes for upcoming Dyninst 11.0 release
Uh, exactly how are you building dyninst api_breakages?

I tried building this directly from cmake using spack-built prereqs.
I get this failure about unable to find libiberty include directory


[  9%] Building CXX object common/CMakeFiles/common.dir/src/addrtranslate-linux.C.o
[  9%] Building CXX object common/CMakeFiles/common.dir/src/symbolDemangleWithCache.C.o
[ 10%] Building C object common/CMakeFiles/common.dir/src/symbolDemangle.c.o
/home/krentel/dyninst/dyninst/common/src/symbolDemangle.c:34:10: fatal error: libiberty/demangle.h: No such file or directory
 #include <libiberty/demangle.h>
          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [common/CMakeFiles/common.dir/build.make:531: common/CMakeFiles/common.dir/src/symbolDemangle.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:516: common/CMakeFiles/common.dir/all] Error 2
make: *** [Makefile:130: all] Error 2


I ran cmake (from a script, so cmake, not ccmake) as:


-DBoost_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/boost-1.72.0-rr5wnwst3gs4d7trleowhmfzozlsfj4b
-DElfUtils_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/elfutils-0.180-ssvmwyzbhnjianyboxxkygoza3mpue74
-DLibIberty_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er
-DTBB_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/intel-tbb-2020.3-ysaadslo6sebbjsfqcczq2mbyndwsb33
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/home/krentel/dyninst/install
-DUSE_OpenMP=ON
-DSTERILE_BUILD=ON


I checked that the libiberty (and other spack) paths are correct,
there is an include directory and it does contain libiberty/demangle.h.


But I noticed in the cmake configure, there are settings for libiberty
lib dirs, not not include dirs.


-- Found LibIberty: /home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64/libiberty.a 
-- LibIberty library dirs: /home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64
-- LibIberty libraries: /home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64/libiberty.a


Same for ccmake, there is no libiberty include variable.

Is it possible that your cmake config is not testing and setting a
libiberty include directory ??

And maybe this fails for me because I'm using STERILE_BUILD and maybe
other builds aren't and thus picking up the system libiberty ??

--Mark




On 10/26/20 16:02, Tim Haines wrote:
Hi, all.

We have several API-breaking changes we want to include in the next major release of Dyninst (11.0). To help everyone prepare for these changes, I've stored them on a topic branch, api_breakages, instead of merging them into master. If you could try building your software against this branch and let me know if you have any troubles (also let me know if you don't have any!), it will very much help us stay ahead of any bumps in the road we may encounter for this upcoming release. I've outlined the specific API changes below.

Many thanks.

 - Tim

P.S. Apologies if you've seen this before. I'm having troubles with the mailing list and my gmail account.


parseAPI

Removed CFGFactory::destroy_all

dyninstAPI

Removed BPatch_regExpr class

Removed "findFunctionByAddr(void *addr)". Replace with either "findFunctionByEntry" or "findFunctionsByAddr". See https://github.com/dyninst/dyninst/issues/820#issuecomment-683375892 for details.

Removed "BPatch_process::enableDumpPatchedImage"

Removed "BPatch_snippet::getCost()", "BPatch_snippet::getCostAtPoint"


patchAPI

"Patcher::create" now returns a "boost::shared_ptr<Patcher>" instead of a "Patcher*"


symtabAPI

If you have any classes which inherit from "SerializerBase" or "Serializable", those base classes should be removed. Please note that this will have no effect on the behavior of your programs as the serialization feature has been disabled since 2012.


_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

[← Prev in Thread] Current Thread [Next in Thread→]