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

["Mark W. Krentel" <krentel@xxxxxxxx>]

Ok, there has been a recent change in how dyninst config treats
libiberty.  My recipe below works for 10.2.1, but fails for both
current master and api_breakages.

In 10.2.1, cmake ignores LibIberty_ROOT_DIR and even says:

CMake Warning:
  Manually-specified variables were not used by the project:
    LibIberty_ROOT_DIR

But master and api_breakages do test for and actually use libiberty
but aren't setting an include directory and thus fail with:

/home/krentel/dyninst/dyninst/common/src/symbolDemangle.c:34:10:
fatal error: libiberty/demangle.h: No such file or directory
 #include <libiberty/demangle.h>

The failure doesn't depend on STERILE build.


So, exactly how are you building dyninst master?
And why are you not seeing build failures like this?

This is a cmake error right?
Not setting an include directory?

--Mark

On 10/27/20 13:16, Mark W. Krentel wrote:

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

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