Re: [DynInst_API:] RFC: require users to have C++11

wrote: On 08/31/2016 12:07 PM, Mark W. Krentel wrote: Ok, I've been sufficiently taunted. Speaking as someone who builds a subset of Dyninst (parseapi + symtabapi) from source and applications that use it (Rice HPCToolkit) on a daily basis Thanks for your input! I'm a bit unsure of just what

Re: [DynInst_API:] RFC: require users to have C++11

Ok, I've been sufficiently taunted. Speaking as someone who builds a subset of Dyninst (parseapi + symtabapi) from source and applications that use it (Rice HPCToolkit) on a daily basis I'm a bit unsure of just what you're suggesting. First, I think it's perfectly ok to require Dyninst

Re: [DynInst_API:] instructionAPI fails on ARM 64

antics are a work-in-progress: I'm continuing to work on adding support for more instructions and fixing whatever bugs I find. Do let me know about other asserts and errors you see! Thanks, Sunny On 9/12/2016 5:59 PM, Mark W. Krentel wrote: I think instructionAPI (or maybe parseAPI) is broken in m

[DynInst_API:] instructionAPI fails on ARM 64

I think instructionAPI (or maybe parseAPI) is broken in master branch on ARM (aarch64). I'm seeing two problems. The small one is a spew of error messages, "Instruction processing threw exception for instruction: ldr X17, [X16 + 3c0]". The bigger one is raising an abort. I'm running this on

[DynInst_API:] segfault in symtab::openFile and ELF wrapper

I'm seeing a very bad bug in recent dyninst master. "Bad" means that I get a segfault in Symtab::openFile(). For me, all I need in a test program is basically: Symtab * the_symtab = NULL; Symtab::openFile(the_symtab, argv[1]); I get a segfault and stack trace like this: #0

[DynInst_API:] symtab openfile still segfaults with old libelf

Bill, Did you indicate that the fix for using the old libelf was merged into master? I'm still seeing the same problem. I just tried this version from master. commit 64edc81ee01131502e2568749f006e3511c44fb6 Merge: d747211 3c12b19 Author: Bill Williams Date: Tue Nov 15

Re: [DynInst_API:] new segfault in ELF xlatetom on powerpc

Two more data points: 1. it works for me on power8/le (po) with elfutils-0.167, building and running the same way that it failed on power7. 2. it fails for me on power7 with elfutils-0.158. So, it looks like a bug specific to big-endian powerpc and not related to elfutils version. And it

[DynInst_API:] build failure in IA_power.C on powerpc

I'm seeing a build failure in IA_power.C in parseAPI. This happens on both big-endian power7 and little-endian power8. /home/krentel/release/BUILD/symtabAPI/dyninst/parseAPI/src/IA_power.C: In member function 'virtual bool Dyninst::InsnAdapter::IA_IAPI::sliceReturn(Dyninst::ParseAPI::Block*,

Re: [DynInst_API:] closeSymtab() throws a ref count assert in 9.3.1

Ok, that seems to fix the problem. At least, it doesn't throw an assert running on complicated binaries (eg, hpcstruct analyzing itself). But I'm struggling to understand your fix. Maybe I'm being dense or missig something obvious. It seems to me that your patch simply changes the body of

Re: [DynInst_API:] dyninst 9.3.2 and gcc 4.4

As Matt points out, Blue Gene doesn't get any updates for front-end compilers. They continue to sit at RH 6.x and gcc/g++ 4.4. The local admins could install later FE compilers, but they don't. Red Hat could do better by providing packages for later compilers. But that's part of the point.

[DynInst_API:] dyninst 9.3.2 and gcc 4.4

I ran into this problem while trying to build Dyninst 9.3.2 on Blue Gene (mira, vesta) at Argonne. Dyninst 9.3.x won't build with GNU 4.4 because the typeCollection destructor in Collections.C uses the C++11 range iterator feature which is not supported in 4.4. 318

Re: [DynInst_API:] Problems with cotire

As we've previously discussed, I've also had problems with cotire. Something over parallel builds when building both static and dynamic libraries. So yes, I'd either like to turn off cotire or else provide an option to turn it off. Master has USE_COTIRE, but it's not exposed, so currently I

Re: [DynInst_API:] change in getFile from libdwarf to libdw

Sasha, I've tested this and I now get the same answers for file paths with master and libdw as with the old 9.3.2 and libdwarf. So, thanks! --Mark On 03/27/18 16:28, Sasha Da Rocha Pinheiro wrote: Hi Mark, I pushed a commit that fixed it, in the way that you suggested at: (1) Declare

[DynInst_API:] new getCompDir is broken

Sasha, I see where you added a method to Module for getCompDir(). Thanks, but the implementation is badly broken. This has to be a per-module answer. But the code for getCompDir() has a single static string comp_dir_str. As a result, every Module returns the same comp dir. Instead, I think

Re: [DynInst_API:] [dyninst/dyninst] 34c5f5: Correcting declaration of variable for the value o...

Ok, with this fix to master, now I'm getting sensible results for getCompDir() on a per-module basis. Btw, although we don't use this right now, I can tell that a couple months down the road, this will become useful to better understand the layout of the source files as we present them in

Re: [DynInst_API:] new-parallel-parsing config is broken for testsuite

I see. I guess nobody told me. Sorry, Thanks, --Mark On 04/23/18 16:33, Xiaozhu Meng wrote: For parallel parsing branch, testsuite is now a submodule. So, please do git submodule init git submodule update ___ Dyninst-api mailing list

[DynInst_API:] new-parallel-parsing config is broken for testsuite

The new-parallel-parsing branch of dyninst has this in the top-level CMakeLists.txt. add_subdirectory(testsuite) But the testsuite directory is empty in the n-p-p branch. As a result, cmake falls over with: -- Found dependency location /home/krentel/config/build-dyninst/dyninstAPI CMake Error

Re: [DynInst_API:] nondeterministic loop tree results with irreducible loops

Xiaozhu, I was able to adapt your patch on the overlapping instructions to our build system. (There was one tiny issue over ah.retreat() versus ah->retreat(), but that was easy.) Now, I don't see any more non-determinism in our hpcstruct answer on x86. I've run it a bunch of times on the

Re: [DynInst_API:] Building Static Libraries

You may also need to turn off cotire. In the past, we've seen problems with cotire and parallel builds. Something about cotire generating some header files twice. In a parallel build, this could result in one process writing a file while another one is reading it and crashing the build. Bill,

Re: [DynInst_API:] Status of Dyninst 10

Stan, As Xiaozhu said, one of the major additions to 10.x will be the merge of the new-parallel-parsing branch. If you want to get a jump on things, you could try building and running the new-parallel-parsing branch. Fairly recent master has been merged into new-par-par, so it should be pretty

Re: [DynInst_API:] spack dyninst/package.py file changes?

Well, spack won't concretize an old version unless it has preferred=True or you specifically ask for it. So, TBB isn't at any greater risk than any other package. If you want to draw the line at 2018.06, then whatever, go ahead. Be sure to put that in the release notes. But if it were me, IMO

Re: [DynInst_API:] spack dyninst/package.py file changes?

I know that dyninst will download and build TBB, elfutils, boost if they're not specified. That's fine that you go the extra mile, but that's not the spack way of doing things. Spack wants to build all the prereqs itself, through the intel-tbb package.py file. (So, it's important to allow -D

Re: [DynInst_API:] spack dyninst/package.py file changes?

On 11/04/18 15:46, Benjamin Welton wrote: Mark, Packages.yaml is site/user specific (at least as per my understanding). > Spack will take the latest version from intel-tbb by default. I do not believe this is true. Spack will only do this if no version of TBB was installed by spack already.

[DynInst_API:] dyninst 10.0 doesn't build with old glibc-headers and elf.h

I've been working on building Dyninst 10.0 on Blue Gene with RedHat 6.x and old glibc-headers and I ran into the following problem. The build dies in Object-elf.C with undefined symbol EM_AARCH64. You've seen this problem before. Elf_X.C and dwarfHandle.C have code to work around an old elf.h

Re: [DynInst_API:] elfutils, elf.h, and dyninst

I was about to warn you that the new config option won't be available until the next release, but I just check the elfutils web site and 0.176 (with the option) was released on Friday, Feb 15. [DIR]0.174/14-Sep-2018 11:44 [DIR]0.175/16-Nov-2018 12:14 [DIR]0.176/

[DynInst_API:] [dyninst/dyninst] 54a2de: Add some explicit casts from boost::tribool to boo...

Branch: refs/heads/master Home: https://github.com/dyninst/dyninst Commit: 54a2debd94c3e8df3b6f1e579f1db02dae61cbb7 https://github.com/dyninst/dyninst/commit/54a2debd94c3e8df3b6f1e579f1db02dae61cbb7 Author: Mark W. Krentel Date: 2019-02-01 (Fri, 01 Feb 2019) Changed paths

[DynInst_API:] [dyninst/dyninst] 54a2debd94c3e8df3b6f1e579f1db02dae61cbb7: Add some explicit casts from boost::tribool to bool for some code in (#541) Add some explicit casts from boost::tribool to bo

Branch: refs/heads/master Home: https://github.com/dyninst/dyninst Commit: 54a2debd94c3e8df3b6f1e579f1db02dae61cbb7 https://github.com/dyninst/dyninst/commit/54a2debd94c3e8df3b6f1e579f1db02dae61cbb7 Author: Mark W. Krentel Date: 2019-02-01T13:14:11-06:00 Changed paths

[DynInst_API:] boost 1.70 breaks dyninst build over checked_delete

This is mostly an early heads up, I'm not blocked or anything. But at some point, you'll need to adapt to some new boost usage. I'll leave it to you to decide if this is needed for 10.1. Before 10.1 would be a bit easier for spack users, so that when 10.1 comes out, then the latest release of

Re: [DynInst_API:] boost 1.70 breaks dyninst build over checked_delete

Will that solution work for both 1.69 and 1.70? That would be the most robust way of handling this, if there's a solution that will work either way, or else a config test and #if. You'd rather not have a hard line where Dyninst 10.0 requires <= 1.69 and Dyninst 10.1 requires >= 1.70. Thanks!

[DynInst_API:] changes to the cmake args for 10.1

One of my cron jobs that builds Dyninst master tripped an alarm today. With the recent commits, the build procedure for master and upcoming 10.1 has changed in a few ways. First question: are the changes to the cmake args (see below) now complete, or are there more to come before 10.1? I would

Re: [DynInst_API:] the PRIx64 commit breaks the build with some

orced a code change before merging this, but it had already been tested by the person who submitted the PR, and it was blocking their build cycle. The correct solution is to use to use std::to_string introduced in C++11. I'll make a PR for that and re-test. Thanks. - Tim On Tue, Aug

Re: [DynInst_API:] the PRIx64 commit breaks the build with some

Thanks. - Tim On Wed, Aug 7, 2019 at 2:03 PM Mark W. Krentel <mailto:kren...@rice.edu>> wrote: Tim, Based on the contents of the file, I don't see where this would be limited to 32-bit. I have seen this on more than just power8. With RH 6.x, it's "broken"

[DynInst_API:] the PRIx64 commit breaks the build with some

One of my cron jobs tripped an alarm for Dyninst master on powerpc this morning. This one is bizarre, but the last commit about the PRIx64 macros breaks the build on some systems, depending on the exact version of the header file. Here is a unit test that reproduces the problem. This is a

[DynInst_API:] [dyninst/dyninst] b98a53: Expand the list of non-returning functions in Code...

Branch: refs/heads/master Home: https://github.com/dyninst/dyninst Commit: b98a53f455e92d577f6f294732ba0712d53c36dc https://github.com/dyninst/dyninst/commit/b98a53f455e92d577f6f294732ba0712d53c36dc Author: Mark W. Krentel Date: 2020-06-01 (Mon, 01 Jun 2020) Changed paths

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

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

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:] building dyninst with intel-oneapi-tbb for TBB

Hi, what are y'all thoughts on building Dyninst with a TBB other than intel-tbb, specifically intel-oneapi-tbb ? Spack has three providers for the virtural tbb: intel-tbb, intel-oneapi-tbb and the full intel-parallel-studio. I get the sense that intel-tbb is older, to be phased out in favor of

Re: [DynInst_API:] build failure on powerpc

hub.com/dyninst/dyninst/pull/1252. That will > likely get merged today. > > Thanks. > -Tim > > On Fri, Apr 8, 2022 at 12:23 PM Mark W. Krentel wrote: > I'm seeing a repeatable build failure for dyninst master on powerpc. > This only happens on ppc64/le (llnl.cs.rice.ed

[DynInst_API:] build failure on powerpc

I'm seeing a repeatable build failure for dyninst master on powerpc. This only happens on ppc64/le (llnl.cs.rice.edu), not x86, not arm. It just started happening today with a few new commits including the new _DEFAULT_SOURCE lines. It looks like something has triggered some arch-specific changes