[DynInst_API:] Abort while building Dyninst with Intel compiler - tbb related

[Jim Galarowicz]

Hi all,

We have a user that wants to build OpenSpeedShop with Intel compilers.   
The compile/compiler is aborting when building Dyninst where it is 
referencing TBB includes.


I wonder if anyone can see any issues with the compiler version, tbb 
version or another thing that might be a problem.


[jeg@login01 include]$ icc -v
icc version 19.0.5.281 (gcc version 4.8.5 compatibility)

*Listing of abort area:*

 96%] Building C object 
CMakeFiles/dyninstAPI_RT.dir/src/RTstatic_ctors_dtors-x86.c.o
[100%] Linking C shared library libdyninstAPI_RT.so
[100%] Built target dyninstAPI_RT
[  0%] Built target DyninstRT
Scanning dependencies of target common
[  1%] Building CXX object common/CMakeFiles/common.dir/src/mcs-lock.C.o
[  1%] Building CXX object common/CMakeFiles/common.dir/src/pfq-rwlock.C.o
[  1%] Building CXX object 
common/CMakeFiles/common.dir/src/race-detector-annotations.C.o
[  1%] Building CXX object common/CMakeFiles/common.dir/src/string-regex.C.o
[  2%] Building CXX object common/CMakeFiles/common.dir/src/Timer.C.o
[  2%] Building CXX object common/CMakeFiles/common.dir/src/Types.C.o
[  2%] Building CXX object common/CMakeFiles/common.dir/src/lprintf.C.o
[  2%] Building CXX object common/CMakeFiles/common.dir/src/pathName.C.o
[  3%] Building CXX object common/CMakeFiles/common.dir/src/Time.C.o
[  3%] Building CXX object common/CMakeFiles/common.dir/src/fraction.C.o
[  3%] Building CXX object common/CMakeFiles/common.dir/src/timing.C.o
[  4%] Building CXX object common/CMakeFiles/common.dir/src/stats.C.o
[  4%] Building CXX object common/CMakeFiles/common.dir/src/Annotatable.C.o
[  4%] Building CXX object common/CMakeFiles/common.dir/src/MappedFile.C.o
[  4%] Building CXX object common/CMakeFiles/common.dir/src/sha1.C.o
[  5%] Building CXX object common/CMakeFiles/common.dir/src/util.C.o
[  5%] Building CXX object common/CMakeFiles/common.dir/src/Node.C.o
[  5%] Building CXX object common/CMakeFiles/common.dir/src/Graph.C.o
[  5%] Building CXX object common/CMakeFiles/common.dir/src/Edge.C.o
[  6%] Building CXX object common/CMakeFiles/common.dir/src/DOT.C.o
[  6%] Building CXX object common/CMakeFiles/common.dir/src/dyn_regs.C.o
[  6%] Building CXX object common/CMakeFiles/common.dir/src/AST.C.o
[  6%] Building CXX object common/CMakeFiles/common.dir/src/addrtranslate.C.o
[  7%] Building CXX object common/CMakeFiles/common.dir/src/arch-x86.C.o
[  7%] Building CXX object common/CMakeFiles/common.dir/src/arch-power.C.o
[  7%] Building CXX object common/CMakeFiles/common.dir/src/arch-aarch64.C.o
[  8%] Building CXX object common/CMakeFiles/common.dir/src/debug_common.C.o
[  8%] Building CXX object common/CMakeFiles/common.dir/src/VariableLocation.C.o
[  8%] Building CXX object common/CMakeFiles/common.dir/src/Buffer.C.o
[  8%] Building CXX object common/CMakeFiles/common.dir/src/MachSyscall.C.o
[  9%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
[  9%] Building CXX object common/CMakeFiles/common.dir/src/timing-linux.C.o
[  9%] Building CXX object common/CMakeFiles/common.dir/src/parseauxv.C.o
[  9%] Building CXX object 
common/CMakeFiles/common.dir/src/addrtranslate-sysv.C.o
[ 10%] Building CXX object 
common/CMakeFiles/common.dir/src/addrtranslate-auxv.C.o
[ 10%] Building CXX object 
common/CMakeFiles/common.dir/src/addrtranslate-linux.C.o
[ 10%] Linking CXX shared library libcommon.so
[ 10%] Built target common
Scanning dependencies of target dynElf
[ 10%] Building CXX object elf/CMakeFiles/dynElf.dir/src/Elf_X.C.o
[ 10%] Linking CXX shared library libdynElf.so
[ 10%] Built target dynElf
Scanning dependencies of target dynDwarf
[ 10%] Building CXX object dwarf/CMakeFiles/dynDwarf.dir/src/dwarfResult.C.o
[ 10%] Building CXX object dwarf/CMakeFiles/dynDwarf.dir/src/dwarfExprParser.C.o
[ 10%] Building CXX object 
dwarf/CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o
[ 11%] Building CXX object dwarf/CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o
[ 11%] Linking CXX shared library libdynDwarf.so
[ 11%] Built target dynDwarf
Scanning dependencies of target symLite
[ 11%] Building CXX object symlite/CMakeFiles/symLite.dir/src/SymLite-elf.C.o
[ 11%] Linking CXX shared library libsymLite.so
[ 11%] Built target symLite
Scanning dependencies of target symtabAPI
[ 12%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Object.C.o
[ 12%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Aggregate.C.o
[ 12%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Function.C.o
[ 12%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Variable.C.o
[ 13%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Symbol.C.o
[ 13%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/LineInformation.C.o
[ 13%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Symtab.C.o
In file included from 
/global/software/centos-7/modules/langs/intel/2019.5.281/compilers_and_libraries_2019.5.281/linux/tbb/include/tbb/tbb_machine.h(245),
 from 

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

[Jim Galarowicz]

Hi Ben, all,
There is a pull request submitted and waiting for approval: 
https://github.com/spack/spack/pull/9728

Jim G

On 11/05/2018 11:57 AM, Benjamin Welton wrote:

Jim,

We are likely okay using either 2019 or 2018.6. So while Dyninst may 
pull 2019 (which is apparently a week older than 2018.6), it should be 
fine. The real reason I want a limit in the depends_on spec is to make 
sure dyninst isn't built with a crazy old version of TBB (and a week 
older isn't a big deal).


Go ahead and submit those changes to Spack (assuming everything builds 
on your end OK). We will revisit these at a later date if need be.


Mark,

> It's actually a pain to get spack to use a previously installed package
because you have to write a dependency spec that *exactly* matches the
installed version

This is the problem with TBB in specific. While most of Dyninst's 
dependencies have very specific recipies that must be built, TBB (at 
least as per my understanding) does not. In this case, there is a much 
higher chance (which could still be low) of a match to an existing 
version. There is a zero chance of a match with an incompatible 
version if we specify that we require at least a certain version of 
the dependency.


The whole reason I am pushing for this is purely that it eliminates 
any chance of a crazy bug being reported by a user that turns out to 
be caused by linking to some ancient version of TBB with spack.


As for going forward, I am going to open a dialog with the spack folks 
about how to best handle package updates (and best practices for doing 
so).


Ben

On Sun, Nov 4, 2018 at 5:54 PM Mark W. Krentel > wrote:


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. If a site has the oldest
> version of TBB supported by spack already installed, that will
be used
> with Dyninst (likely something we dont want).
>

No, spack spec resolution does not depend on what's currently
installed.  That would actually be hard to add (and I claim NP-hard in
general).

What actually happens is that it resolves the partial spec into a
completely specified spec and if that *exact* hash has already been
installed, then it uses it, otherwise it builds the new hash.

Here's a simple example.  I installed an old version of libiberty+pic
2.28.1.

  $ ./spack find -v -l
==> 1 installed packages.
-- linux-fedora26-x86_64 / gcc@7.3.1 
dz45txs libiberty@2.28.1+pic

Then, I use 'spack spec' to see how it would build dynisnt (omitting
many transitive dependencies).

$ ./spack spec dyninst
dyninst@9.3.2%gcc@7.3.1~stat_dysect arch=linux-fedora26-x86_64
     ^boost@1.68.0%gcc@7.3.1+atomic+chrono~clanglibcpp cxxstd=default

+date_time~debug+exception+filesystem+graph~icu+iostreams+locale+log+math~mpi+multithreaded~numpy

patches=2ab6c72d03dec6a4ae20220a9dfd5c8c572c5294252155b85c6874d97c323199


+program_options~python+random+regex+serialization+shared+signals~singlethreaded+system~taggedlayout+test+thread+timer~versionedlayout+wave

arch=linux-fedora26-x86_64
     ^cmake@3.12.3%gcc@7.3.1~doc+ncurses+openssl+ownlibs
patches=dd3a40d4d92f6b2158b87d6fb354c277947c776424aa03f6dc8096cf3135f5d0

~qt arch=linux-fedora26-x86_64
     ^elfutils@0.173%gcc@7.3.1~bzip2+nls~xz arch=linux-fedora26-x86_64
     ^libdwarf@20180129%gcc@7.3.1 arch=linux-fedora26-x86_64
     ^libiberty@2.31.1%gcc@7.3.1+pic arch=linux-fedora26-x86_64

So, it would build dyninst with 2.31.1, even though 2.28.1 is already
installed.

It's actually a pain to get spack to use a previously installed
package
because you have to write a dependency spec that *exactly* matches the
installed version.  If this is what you want, the easiest way is to
use '/hash' for the dependency.

$ ./spack spec dyninst ^libiberty /dz45txs
dyninst@9.3.2%gcc@7.3.1~stat_dysect arch=linux-fedora26-x86_64
     ^libiberty@2.28.1%gcc@7.3.1+pic arch=linux-fedora26-x86_64

Here, '/dz45txs' refers to the installed version.  Note that
/dz45txs must have +pic or else it won't match dyninst's needs.

Also, I should have clarified what I said about the preferred version.
If a version specifies 'preferred=True', then that's preferred (duh).
Otherwise, it's the latest rev according to some ordering.

Jim G, that's why the order you put them in the file doesn't matter.
2019 > 2018 no matter what order you write them.

Btw, you can call this a deficiency is spack's features.  What you'd
like to say is that you *prefer* a version >= 2018.06 without
requiring that.  But 

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

[Jim Galarowicz]

Hi Ben,

No matter if I put the 2018.6 line before or after the 2019 line, 2019 
will be built
because it is numerically higher than 2018.6.  I believe that is the 
logic spack uses.


class IntelTbb(Package):
    """Widely used C++ template library for task parallelism.
    Intel Threading Building Blocks (Intel TBB) lets you easily write 
parallel
    C++ programs that take full advantage of multicore performance, 
that are

    portable and composable, and that have future-proof scalability.
    """
    homepage = "http://www.threadingbuildingblocks.org/;

    # See url_for_version() below.
*   version('2018.6', '9a0f78db4f72356068b00f29f54ee6bc')*
    version('2019',   '2119f1db2f905dc5b423482d7689b7d6')
    version('2018.5', 'ff3ae09f8c23892fbc3008c39f78288f')
    version('2018.4', '5e2e6ba0e25624a94331c945856551c2')
    version('2018.3', 'cd2e136598ffa5c136f077ee85a35b4c')
    version('2018.2', '0b8dfe30917a54e40828eeb0ed7562ae')
    version('2018.1', 'b2f2fa09adf44a22f4024049907f774b')

==> elfutils is already installed in 
/home/jeg/OSS_SPACK/spack/opt/spack/linux-fedora27-x86_64/gcc-7.2.1/elfutils-0.173-5jj6vo36rcaqvyqe2yh25q3sobtt4xly

==> Installing intel-tbb
*==> Fetching https://github.com/01org/tbb/archive/2019.tar.gz*
 
100.0%
==> Staging archive: 
/home/jeg/OSS_SPACK/spack/var/spack/stage/intel-tbb-2019-yibspv36ojjkcjj4tq7iwsyct4lfixj6/2019.tar.gz
==> Created stage in 
/home/jeg/OSS_SPACK/spack/var/spack/stage/intel-tbb-2019-yibspv36ojjkcjj4tq7iwsyct4lfixj6

==> Applied patch tbb_cmakeConfig.patch
==> Building intel-tbb [Package]
==> Executing phase: 'install'
==> Successfully installed intel-tbb
  Fetch: 1.40s.  Build: 14.28s.  Total: 15.68s.
[+] 
/home/jeg/OSS_SPACK/spack/opt/spack/linux-fedora27-x86_64/gcc-7.2.1/intel-tbb-2019-yibspv36ojjkcjj4tq7iwsyct4lfixj6
==> libiberty is already installed in 
/home/jeg/OSS_SPACK/spack/opt/spack/linux-fedora27-x86_64/gcc-7.2.1/libiberty-2.31.1-7vfoqwkbgkrslrpuwzuyehuna6v5dvp7

==> Installing dyninst
==> Cloning git repository: https://github.com/dyninst/dyninst.git on 
branch master

==> No checksum needed when fetching with git
==> Already staged dyninst-develop-23i3tj4axmub7plsfyy2vid5tzjfd5gn in 
/home/jeg/OSS_SPACK/spack/var/spack/stage/dyninst-develop-23i3tj4axmub7plsfyy2vid5tzjfd5gn

==> No patches needed for dyninst
==> Building dyninst [Package]
==> Executing phase: 'install'
==> Successfully installed dyninst
  Fetch: 3.55s.  Build: 7m 30.67s.  Total: 7m 34.22s.
[+] 
/home/jeg/OSS_SPACK/spack/opt/spack/linux-fedora27-x86_64/gcc-7.2.1/dyninst-develop-23i3tj4axmub7plsfyy2vid5tzjfd5gn


So, if that is ok with the dyninst team, then the spack 
modifications/suggestions work to build dyninst with tbb.


Discuss it with your team and Mark K. and let me know how you want to 
proceed.

I will do some execution testing to see if it works with O|SS now.

Thanks,
Jim G


On 11/04/2018 03:46 PM, 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. If a site has the oldest 
version of TBB supported by spack already installed, that will be used 
with Dyninst (likely something we dont want).


Jim, if you want to give it a try my suggested changes are the 
following (if these work, then it is likely good to submit to spack as 
a pull request):


TBB Package.py:

version('2018.6', ' 9a0f78db4f72356068b00f29f54ee6bc')

Dyninst Package.py:

depends_on("tbb@2018.6:")

(then your other changes).

As for going forward, I am going to suggest on Monday that we 
(dyninst) keeps a running github fork of spack where we make changes 
to the packages for dyninst. That way we have a single location that 
we can grant access to and allow for commits/testing before submitting 
a pull request to the main spack repo.


Ben


On Sun, Nov 4, 2018 at 1:24 PM Mark W. Krentel > wrote:


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 vars for all the
external prereqs.)

As for version, I suggest you leave this unspecified in the dyninst
recipe.  Just use depends_on('tbb').  This is what the packages.yaml
file is for.

Spack will take the latest version from intel-tbb by default. So
unless there's some version that's completely incompatible, I suggest
don't add unnecessary constraints.  Let someone specify this in
packages.yaml.

Of course, if you want to update the intel-tbb recipe, that's fine,
but that's a separate question.

Btw, I was planning on 

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

[Jim Galarowicz]

Hi Ben, Xiaozhu,

This website (https://github.com/01org/tbb/releases) claims that the 
2018_U6 release is the latest.   So, it seems like a logical step to add 
it to the tbb/package.py file.


The tbb version naming scheme seems difficult since there are 2019 
versions already there.


Ben - maybe we also need to add the 10.0 release to this if: if 
spec.satisfies('@develop'):  so that we won't have to change the 
package.py file again when 10.0 is released?


Maybe this would work:    if spec.satisfies('@develop') or 
spec.satisfies('@10.0:'):


              if spec.satisfies('@develop'):
+                args.append('-DTBB_INCLUDE_DIRS=%s' %
spec['tbb'].prefix.include)
+                args.append('-DTBB_LIBRARIES=%s'   % join_path(
+                    spec['tbb'].prefix.lib, "libtbb." + dso_suffix))

Let me know if you want to submit both the dyninst and tbb changes or if 
you want me to help.


Thanks,
Jim G


On 11/04/2018 11:19 AM, Benjamin Welton wrote:
It is not my TBB spack package. That is from spacks TBB package. It's 
not supported because no one added it to the spack recipe. We can 
submit a pull request to add that version to spack.


Ben

On Sun, Nov 4, 2018, 8:33 AM Xiaozhu Meng <mailto:xm...@cs.wisc.edu>> wrote:


Hi Ben,

Dyninst will automatically download the following version of TBB:

URL https://github.com/01org/tbb/archive/2018_U6.tar.gz
URL_MD5 9a0f78db4f72356068b00f29f54ee6bc

It looks like this version is not in your TBB version list. Is the
above not supported by spack?

Thanks,

--Xiaozhu

On Sat, Nov 3, 2018 at 9:41 PM Benjamin Welton mailto:wel...@cs.wisc.edu>> wrote:

Jim,

The only modification I would suggest is that we add a minimum
version required to the TBB depends_on specification.

Xiaozhu, which of the following versions of TBB should we
consider to be the minimum required for dyninst to build? We
also have the option of requiring a specific version (and only
that version) or no requirement (which is already what Jim's
fix does)? If we don't know, I suggest we use whatever dyninst
is building right now as the minimum in case there are bugs in
older versions we are not aware of.

    version('2019',  '2119f1db2f905dc5b423482d7689b7d6')
    version('2018.5', 'ff3ae09f8c23892fbc3008c39f78288f')
    version('2018.4', '5e2e6ba0e25624a94331c945856551c2')
    version('2018.3', 'cd2e136598ffa5c136f077ee85a35b4c')
    version('2018.2', '0b8dfe30917a54e40828eeb0ed7562ae')
    version('2018.1', 'b2f2fa09adf44a22f4024049907f774b')
    version('2018',  '7fb30d5ea2545f26ce02757d9ab05e6c')
    version('2017.8', '7240f57f1aeea0e266a5e17ae68fdc16')
    version('2017.7', '364f2a4b80e978f38a69cbf7c466b898')
    version('2017.6', 'ec21254af4fc2a29574c272f501a3138')
    version('2017.5', '85b41c64102c052e24d8a39f6193e599')
    version('2017.4', '71526b2fef098515e212302d1455de7d')
    version('2017.3', 'd7622eeaafeff8d271c7aa684bd82ddb')
    version('2017.2', '9605cbea96998a10a186fc72c35cbd76')
    version('2017.1', '6c0fe8aa7bc911a85e8e522e620511b3')
    version('2017',  '9e7f9ea684ecf84ac74dcd3c6012cfa6')
    version('4.4.6', '20e15206f70c2651bfc964e451a443a0')
    version('4.4.5', '531a67cd98f9b4ec8ece95c5f8193a83')
    version('4.4.4', '61531b2e8684e06a621dcdca1a7a420e')
    version('4.4.3', '8e3e39e1fdfb3f7c3a5ac8ec1afe186e')
    version('4.4.2', 'e92b110e8eb238741b00e3789b39969e')
    version('4.4.1', 'a02c9958f02c1b5f3626874219979ae8')
    version('4.4', '1d512085221996eae6cec04e1a4cd3dd')

Ben

On Sat, Nov 3, 2018 at 5:21 PM Jim Galarowicz
mailto:j...@krellinst.org>> wrote:

Hi all,

Because dyninst has a new TBB dependency mods to the spack
dyninst/package.py file are necessary.

I was able to build dyninst master (dyninst@develop spack
version) with
spack using these mods to the dyninst/package.py file.

Do these fit with what the dyninst team has in mind?
We need this as we have dependencies on the latest dyninst
version for
OpenSpeedShop.
Let me know, I can submit these to spack or if someone has
something
better please submit it.

Thanks,
Jim G


diff --git
a/var/spack/repos/builtin/packages/dyninst/package.py
b/var/spack/repos/builtin/packages/dyninst/package.py
index 5b0aea4..5fc843d 100644
--- a/var/spack/repos/builtin/packages/dyninst/package.py
+++ b/var/spack/repos/builtin/packages/dyninst/package.py
@@ -40,6 +40,7 @@ class Dyninst(Package):
  

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

[Jim Galarowicz]

Hi all,

Because dyninst has a new TBB dependency mods to the spack 
dyninst/package.py file are necessary.


I was able to build dyninst master (dyninst@develop spack version) with 
spack using these mods to the dyninst/package.py file.


Do these fit with what the dyninst team has in mind?
We need this as we have dependencies on the latest dyninst version for 
OpenSpeedShop.
Let me know, I can submit these to spack or if someone has something 
better please submit it.


Thanks,
Jim G


diff --git a/var/spack/repos/builtin/packages/dyninst/package.py 
b/var/spack/repos/builtin/packages/dyninst/package.py

index 5b0aea4..5fc843d 100644
--- a/var/spack/repos/builtin/packages/dyninst/package.py
+++ b/var/spack/repos/builtin/packages/dyninst/package.py
@@ -40,6 +40,7 @@ class Dyninst(Package):
 depends_on("libdwarf", when='@:9')
 depends_on("boost@1.42:")
 depends_on('libiberty+pic')
+depends_on('tbb')
 depends_on('cmake', type='build')

 patch('stat_dysect.patch', when='+stat_dysect')
@@ -73,6 +74,9 @@ class Dyninst(Package):
 # For @develop + use elfutils libdw, libelf is an abstraction
 # we are really using elfutils here
 if spec.satisfies('@develop'):
+args.append('-DTBB_INCLUDE_DIRS=%s' % 
spec['tbb'].prefix.include)

+args.append('-DTBB_LIBRARIES=%s'   % join_path(
+spec['tbb'].prefix.lib, "libtbb." + dso_suffix))
 args.append('-DLIBDWARF_INCLUDE_DIR=%s' % libelf.include)
 args.append('-DLIBDWARF_LIBRARIES=%s'   % join_path(
 libelf.lib, "libdw." + dso_suffix))

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

Re: [DynInst_API:] Dyninst abort on running GEMM on the Power9 cluster

[Jim Galarowicz]

Hi all,

Posting again without the library attached - the first email went to the 
moderator list.


Jim G


On 10/26/2018 09:59 AM, Jim Galarowicz wrote:


Hi Dyninst team,

Here is the abort and output from running GEMM (mpi shoc cuda 
benchmark) with our CUDA experiment osscuda.


It seems like Dyninst is trying to get a Dwarf handle on this file:  
/usr/lib64/libcuda.so.410.48 when we abort.


This is from using Dyninst master top of tree from October 23, 2018.  
When I go back to the September 15, 2018 top of tree I do not see the 
abort.
That seems to indicate that it is a Dyninst issue, so I'm sending this 
in because our spack build of O|SS depends on your top of tree, until 
10.0 is released.


Let me know if you need more information.   I attached the file above 
- gzipped.


Thanks,
Jim G

Here is the output from the run and the core traceback information.

[jeg@p9-4V100-01 CUDA]$ ulimit -c unlimited
[jeg@p9-4V100-01 CUDA]$ ulimit -c
unlimited
[jeg@p9-4V100-01 CUDA]$ *osscuda "mpirun -np 2 ./GEMM"*
[openss]: cuda counting all instructions for CPU and GPU.
[openss]: cuda using default periodic sampling rate (10 ms).
[openss]: cuda configuration: 
"interval=1000,PAPI_TOT_INS,inst_executed"

Creating topology file for frontend host p9-4V100-01
Generated topology file: ./cbtfAutoTopology
Running cuda collector.
Program: mpirun -np 2 ./GEMM
Number of mrnet backends: 2
Topology file used: ./cbtfAutoTopology
executing mpi program: mpirun -np 2  cbtfrun  --mpi  --mrnet -c cuda 
./GEMM

MPI Task 0/1 starting
MPI Task 1/1 starting
Chose device: name='Tesla V100-SXM2-16GB' index=0
Chose device: name='Tesla V100-SXM2-16GB' index=1
Running single precision test
Running single precision test
Running double precision test
Running double precision test
test    atts    units    median    mean    stddev    min max
DGEMM-N(max)    128    GFlops    9.69694    9.69694 2.91311    
6.78383    12.61
DGEMM-N(mean)    128    GFlops    6.3096    6.3096 0.64253    
5.66707    6.95213
DGEMM-N(median)    128    GFlops    6.44043    6.44043 0.954308    
5.48612    7.39473
DGEMM-N(min)    128    GFlops    2.74011    2.74011 1.78164    
0.958474    4.52175
DGEMM-N(stddev)    128    GFlops    2.12004    2.12004 1.32167    
0.798364    3.44171
DGEMM-N_PCIe(max)    128    GFlops    0.986637    0.986637 0.382143    
0.604494    1.36878
DGEMM-N_PCIe(mean)    128    GFlops    0.883682    0.883682 
0.290739    0.592943    1.17442
DGEMM-N_PCIe(median)    128    GFlops    0.931726 0.931726    
0.339714    0.592012    1.27144
DGEMM-N_PCIe(min)    128    GFlops    0.584403    0.584403 
0.00570615    0.578697    0.590109
DGEMM-N_PCIe(stddev)    128    GFlops    0.119548 0.119548    
0.110633    0.00891468    0.230181
DGEMM-N_Parity(max)    128    N    9.21747    9.21747 1.00485    
8.21262    10.2223
DGEMM-N_Parity(mean)    128    N    6.53364    6.53364 2.00588    
4.52775    8.53952
DGEMM-N_Parity(median)    128    N    6.54143    6.54143 1.72542    
4.81601    8.26685
DGEMM-N_Parity(min)    128    N    3.71895    3.71895 3.09472    
0.624231    6.81368
DGEMM-N_Parity(stddev)    128    N    1.72226    1.72226 0.519237    
1.20303    2.2415
DGEMM-T(max)    128    GFlops    8.73437    8.73437 1.89898    
6.83539    10.6334
DGEMM-T(mean)    128    GFlops    5.84512    5.84512 0.200883    
5.64424    6.04601
DGEMM-T(median)    128    GFlops    6.43896    6.43896 0.641068    
5.7979    7.08003
DGEMM-T(min)    128    GFlops    2.19582    2.19582 2.05793    
0.137885    4.25375
DGEMM-T(stddev)    128    GFlops    2.08324    2.08324 1.28537    
0.797875    3.36861
DGEMM-T_PCIe(max)    128    GFlops    0.973304    0.973304 0.368403    
0.604901    1.34171
DGEMM-T_PCIe(mean)    128    GFlops    0.837045    0.837045 
0.244427    0.592618    1.08147
DGEMM-T_PCIe(median)    128    GFlops    0.928633 0.928633    
0.333162    0.59547    1.2618
DGEMM-T_PCIe(min)    128    GFlops    0.350296    0.350296 0.223772    
0.126523    0.574068
DGEMM-T_PCIe(stddev)    128    GFlops    0.186293 0.186293    
0.176799    0.00949395    0.363091
DGEMM-T_Parity(max)    128    N    8.61263    8.61263 1.68739    
6.92524    10.3
DGEMM-T_Parity(mean)    128    N    6.22137    6.22137 2.28375    
3.93762    8.50512
DGEMM-T_Parity(median)    128    N    6.67385    6.67385 2.0628    
4.61105    8.73666
DGEMM-T_Parity(min)    128    N    3.24982    3.24982 3.16002    
0.0898014    6.40984
DGEMM-T_Parity(stddev)    128    N    1.69809    1.69809 0.495801    
1.20229    2.19389
SGEMM-N(max)    256    GFlops    62.1606    62.1606 7.55859    
54.602    69.7191
SGEMM-N(mean)    256    GFlops    47.9714    47.9714 1.68053    
46.2909    49.652
SGEMM-N(median)    256    GFlops    54.0888    54.0888 6.28268    
47.8061    60.3715
SGEMM-N(min)    256    GFlops    20.6876    20.6876 6.84074    
13.8469    27.5284
SGEMM-N(stddev)    256    GFlops    14.7462    14.7462 6.70088    
8.0453    21.4471
SGEMM-N_PCIe(max)    256    GFlops    10.325

[DynInst_API:] Compiler error with Dyninst master on Power9 system.

[Jim Galarowicz]

Hi all,
I'm seeing this compile error with dyninst master on a IBM Power 9 
system - (master as of Oct 15, 2018 5 pm CT.).

Thanks,
Jim G.

*==>*  libiberty is already installed in 
/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/libiberty-2.31.1-ignef7ht5g7phjabqd2252uhpfy7c2dr
*==>*  *Installing*  *dyninst*
*==>*  Cloning git repository: https://github.com/dyninst/dyninst.git on branch 
master
*==>*  No checksum needed when fetching with git
*==>*  Already staged dyninst-develop-a4xv5a53d47brdku5nthviq3zzm6euq5 in 
/home/jeg/spack/var/spack/stage/dyninst-develop-a4xv5a53d47brdku5nthviq3zzm6euq5
*==>*  No patches needed for dyninst
*==>*  Building dyninst [Package]
*==>*  Executing phase: 'install'
*==>*  Error: ProcessError: Command exited with status 2:
'make' '-j160'

4 errors found in build log:
 2263[ 93%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/syscallNotification.C.o
 2264[ 93%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/syscall-linux.C.o
 2265cd /tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI 
&& /home/jeg/spack/lib/spack/env/gcc/g++  -DBOOST_ALL_NO_LI
 B=1 -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBPATCH_DLL_BUILD 
-DUSE_PARSE_API -DWITHOUT_SYMLITE -DWITH_SYMTAB_API -Darch_64bit -Da
 rch_power -Darch_ppc_little_endian -Dbug_force_terminate_failure 
-Dbug_registers_after_exit -Dbug_syscall_changepc_rewind -Dcap_32_64
  -Dcap_async_events -Dcap_binary_rewriter -Dcap_dwarf 
-Dcap_dynamic_heap -Dcap_liveness -Dcap_mutatee_traps -Dcap_ptrace -Dcap_regist
 ers -Dcap_thread_db -Dcap_threads -Dcap_toc_64 
-DdyninstAPI_EXPORTS -Dos_linux -Dppc64_linux 
-I/home/jeg/spack/opt/spack/linux-centos
 
7-ppc64le/gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include/libelf
 -I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/
 gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include 
-I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/boost-1
 .68.0-f4oci35ae2bbwkqgkc32gkw2fbx6ui5a/include 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build 
-I/tmp/jeg/spack-stage/s
 pack-stage-5wK0IO/dyninst/spack-build/common/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/common/h 
-I/tmp/jeg/spack-stage/spac
 k-stage-5wK0IO/dyninst/dataflowAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dyninstAPI/h 
-I/tmp/jeg/spack-stage/spack-stag
 e-5wK0IO/dyninst/instructionAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/parseAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK
 0IO/dyninst/patchAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/proccontrol/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyni
 nst/stackwalk/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/symtabAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dwarf
 /h -I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/elf/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/symlite/h -I/tmp/jeg/spa
 ck-stage/spack-stage-5wK0IO/dyninst 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/external 
-I/tmp/jeg/spack-stage/spack-stage-5wK
 0IO/dyninst/dyninstAPI/src  -std=c++11 -m64  -fvisibility=hidden 
-fvisibility-inlines-hidden -W -Wall -Wpointer-arith -Wcast-qual -Wo
 verloaded-virtual -Wcast-align -Wno-non-template-friend 
-Wno-unused-local-typedefs -Wno-deprecated-declarations -O2 -g  -fPIC   -Winv
 alid-pch -include 
/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI/cotire/dyninstAPI_CXX_prefix.hxx
 -o CMakeFil
 es/dyninstAPI.dir/src/syscallNotification.C.o -c 
/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dyninstAPI/src/syscallNotification.C
 2266cd /tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI 
&& /home/jeg/spack/lib/spack/env/gcc/g++  -DBOOST_ALL_NO_LI
 B=1 -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBPATCH_DLL_BUILD 
-DUSE_PARSE_API -DWITHOUT_SYMLITE -DWITH_SYMTAB_API -Darch_64bit -Da
 rch_power -Darch_ppc_little_endian -Dbug_force_terminate_failure 
-Dbug_registers_after_exit -Dbug_syscall_changepc_rewind -Dcap_32_64
  -Dcap_async_events -Dcap_binary_rewriter -Dcap_dwarf 
-Dcap_dynamic_heap -Dcap_liveness -Dcap_mutatee_traps -Dcap_ptrace -Dcap_regist
 ers -Dcap_thread_db -Dcap_threads -Dcap_toc_64 
-DdyninstAPI_EXPORTS -Dos_linux -Dppc64_linux 
-I/home/jeg/spack/opt/spack/linux-centos
 
7-ppc64le/gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include/libelf
 -I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/
 gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include 
-I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/boost-1
 .68.0-f4oci35ae2bbwkqgkc32gkw2fbx6ui5a/include 

[DynInst_API:] Compiler error with Dyninst master on Power9 system.

[Jim Galarowicz]

Hi all,
I'm seeing this compile error with dyninst master on a IBM Power 9 
system - (master as of Oct 15, 2018 5 pm CT.).

Thanks,
Jim G.

*==>*  libiberty is already installed in 
/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/libiberty-2.31.1-ignef7ht5g7phjabqd2252uhpfy7c2dr
*==>*  *Installing*  *dyninst*
*==>*  Cloning git repository:https://github.com/dyninst/dyninst.git  on branch 
master
*==>*  No checksum needed when fetching with git
*==>*  Already staged dyninst-develop-a4xv5a53d47brdku5nthviq3zzm6euq5 in 
/home/jeg/spack/var/spack/stage/dyninst-develop-a4xv5a53d47brdku5nthviq3zzm6euq5
*==>*  No patches needed for dyninst
*==>*  Building dyninst [Package]
*==>*  Executing phase: 'install'
*==>*  Error: ProcessError: Command exited with status 2:
'make' '-j160'

4 errors found in build log:
 2263[ 93%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/syscallNotification.C.o
 2264[ 93%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/syscall-linux.C.o
 2265cd /tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI 
&& /home/jeg/spack/lib/spack/env/gcc/g++  -DBOOST_ALL_NO_LI
 B=1 -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBPATCH_DLL_BUILD 
-DUSE_PARSE_API -DWITHOUT_SYMLITE -DWITH_SYMTAB_API -Darch_64bit -Da
 rch_power -Darch_ppc_little_endian -Dbug_force_terminate_failure 
-Dbug_registers_after_exit -Dbug_syscall_changepc_rewind -Dcap_32_64
  -Dcap_async_events -Dcap_binary_rewriter -Dcap_dwarf 
-Dcap_dynamic_heap -Dcap_liveness -Dcap_mutatee_traps -Dcap_ptrace -Dcap_regist
 ers -Dcap_thread_db -Dcap_threads -Dcap_toc_64 
-DdyninstAPI_EXPORTS -Dos_linux -Dppc64_linux 
-I/home/jeg/spack/opt/spack/linux-centos
 
7-ppc64le/gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include/libelf
 -I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/
 gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include 
-I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/boost-1
 .68.0-f4oci35ae2bbwkqgkc32gkw2fbx6ui5a/include 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build 
-I/tmp/jeg/spack-stage/s
 pack-stage-5wK0IO/dyninst/spack-build/common/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/common/h 
-I/tmp/jeg/spack-stage/spac
 k-stage-5wK0IO/dyninst/dataflowAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dyninstAPI/h 
-I/tmp/jeg/spack-stage/spack-stag
 e-5wK0IO/dyninst/instructionAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/parseAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK
 0IO/dyninst/patchAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/proccontrol/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyni
 nst/stackwalk/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/symtabAPI/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dwarf
 /h -I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/elf/h 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/symlite/h -I/tmp/jeg/spa
 ck-stage/spack-stage-5wK0IO/dyninst 
-I/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/external 
-I/tmp/jeg/spack-stage/spack-stage-5wK
 0IO/dyninst/dyninstAPI/src  -std=c++11 -m64  -fvisibility=hidden 
-fvisibility-inlines-hidden -W -Wall -Wpointer-arith -Wcast-qual -Wo
 verloaded-virtual -Wcast-align -Wno-non-template-friend 
-Wno-unused-local-typedefs -Wno-deprecated-declarations -O2 -g  -fPIC   -Winv
 alid-pch -include 
/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI/cotire/dyninstAPI_CXX_prefix.hxx
 -o CMakeFil
 es/dyninstAPI.dir/src/syscallNotification.C.o -c 
/tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/dyninstAPI/src/syscallNotification.C
 2266cd /tmp/jeg/spack-stage/spack-stage-5wK0IO/dyninst/spack-build/dyninstAPI 
&& /home/jeg/spack/lib/spack/env/gcc/g++  -DBOOST_ALL_NO_LI
 B=1 -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBPATCH_DLL_BUILD 
-DUSE_PARSE_API -DWITHOUT_SYMLITE -DWITH_SYMTAB_API -Darch_64bit -Da
 rch_power -Darch_ppc_little_endian -Dbug_force_terminate_failure 
-Dbug_registers_after_exit -Dbug_syscall_changepc_rewind -Dcap_32_64
  -Dcap_async_events -Dcap_binary_rewriter -Dcap_dwarf 
-Dcap_dynamic_heap -Dcap_liveness -Dcap_mutatee_traps -Dcap_ptrace -Dcap_regist
 ers -Dcap_thread_db -Dcap_threads -Dcap_toc_64 
-DdyninstAPI_EXPORTS -Dos_linux -Dppc64_linux 
-I/home/jeg/spack/opt/spack/linux-centos
 
7-ppc64le/gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include/libelf
 -I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/
 gcc-4.8.5/elfutils-0.173-klqjzo2qjunbryiykm3fdqzromtoq3ju/include 
-I/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/boost-1
 .68.0-f4oci35ae2bbwkqgkc32gkw2fbx6ui5a/include 

Re: [DynInst_API:] Compile errors in Object-elf.C with latest source top of tree

[Jim Galarowicz]

Hi John,

Thanks for the response!  We have an issue with MRNet needing the 
libstdc++ library, used in the build, available on the compute node when 
we execute.


So we try to use the default compilers if we can.   Otherwise, we have 
to make the build machine libstdc++ library available on the compute nodes.


Sasha pointed out we need a newer boost version.   Our build script 
found boost-1.53 installed on that platform, so I'll force the build to 
build a newer version and see if that works.


Thanks,
Jim G


On 09/15/2018 12:06 PM, John Mellor-Crummey wrote:

Jim,

I compile at Sandia too. Why don’t you use a module with a newer compiler? Try

module load gnu

--
John Mellor-Crummey

(sent from my phone)


On Sep 15, 2018, at 6:24 PM, Jim Galarowicz  wrote:

Hi all,

With the latest dyninst sources, I'm seeing these compile errors with gcc-4.9.3 
at SNL.

Dyninst compiled without error on my laptop with 7.2.1 gcc.

Thanks,

Jim G

grep -n emplace_back */*/*

symtabAPI/src/dwarfWalker.C:292: srcFiles->emplace_back("Unknown file","");
symtabAPI/src/dwarfWalker.C:311: srcFiles->emplace_back(s_name,"");
symtabAPI/src/Object-elf.C:4364: strings->emplace_back("","");
symtabAPI/src/Object-elf.C:4378: strings->emplace_back(tmp, tmp);
symtabAPI/src/Object-elf.C:4382: strings->emplace_back(filename,f);
symtabAPI/src/Object-elf.C:4526: strings->emplace_back("","");
symtabAPI/src/Object-elf.C:4538: strings->emplace_back(tmp,tmp);
symtabAPI/src/Object-elf.C:4542: strings->emplace_back(filename,f);


  22%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/SymtabReader.C.o
[ 22%] Building CXX object symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:
 In member function ‘virtual void 
Dyninst::SymtabAPI::Object::parseLineInfoForCU(Dwarf_Die, 
Dyninst::SymtabAPI::LineInformation*)’:
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:4364:14: error: ‘class 
boost::multi_index::multi_index_container, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::str)> >, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::filename)> > > >’ 
has no member named ‘emplace_back’
  strings->emplace_back("","");
   ^
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:4378:22: error: ‘class 
boost::multi_index::multi_index_container, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::str)> >, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::filename)> > > >’ 
has no member named ‘emplace_back’
  strings->emplace_back(tmp, tmp);
   ^
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:4382:22: error: ‘class 
boost::multi_index::multi_index_container, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::str)> >, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::filename)> > > >’ 
has no member named ‘emplace_back’
  strings->emplace_back(filename,f);
   ^
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:
 In member function ‘Dyninst::SymtabAPI::LineInformation* 
Dyninst::SymtabAPI::Object::parseLineInfoForObject(Dyninst::SymtabAPI::StringTablePtr)’:
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:4526:14: error: ‘class 
boost::multi_index::multi_index_container, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::str)> >, 
boost::multi_index::ordered_non_unique, 
((const std::basic_string Dyninst::SymtabAPI::StringTableEntry::*)::SymtabAPI::StringTableEntry::filename)> > > >’ 
has no member named ‘emplace_back’
  strings->emplace_back("","");
   ^
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login2/dyninst-20180915/symtabAPI/src/Object-elf.C:4538:22: error: ‘class 
boost::multi_index::multi_index_container, 
boost::multi_in

Re: [DynInst_API:] Compile error with master dyninst sources

[Jim Galarowicz]

Hi John, Sasha,

Thanks!   I will get elfutils-0.173 and build with that.

Thanks again!

Jim G

On 08/12/2018 01:32 PM, Sasha Da Rocha Pinheiro wrote:

"make clean" should fix it, if you're not using your system's elfutils.


Get Outlook for Android <https://aka.ms/ghei36>


*From:* Dyninst-api  on behalf of 
John Mellor-Crummey 

*Sent:* Sunday, August 12, 2018 12:09:10 PM
*To:* Jim Galarowicz
*Cc:* dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:] Compile error with master dyninst sources
Jim,

You need to use elfutils 0.173, which provides this new function. This 
new version of elfutils also fixes some infinite loop issues that I 
have observed with Dyninst and elfutils.

--
John Mellor-CrummeyProfessor
Dept of Computer ScienceRice University
email: joh...@rice.edu <mailto:joh...@rice.edu>phone: 713-348-5179

On Aug 12, 2018, at 11:30 AM, Jim Galarowicz <mailto:j...@krellinst.org>> wrote:


Hi all,

I'm trying to build the master git version of dyninst, but I'm 
getting this error.


Has anyone else hit this compile error?

Thanks,

Jim G


[ 12%] Built target symLite
[ 17%] Built target instructionAPI
[ 17%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
/usr/global/tools/openspeedshop/oss-dev/openspeedshop-externals/BUILD/surface86/dyninst-20180810/symtabAPI/src/Object-elf.C: 
In member function 'void 
Dyninst::SymtabAPI::Object::parseLineInfo(Dyninst::SymtabAPI::LineInformation*)':
/usr/global/tools/openspeedshop/oss-dev/openspeedshop-externals/BUILD/surface86/dyninst-20180810/symtabAPI/src/Object-elf.C:4491:52: 
error: 'dwarf_next_lines' was not declared in this scope

 , , , )) == 0)
    ^
make[2]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o] 
Error 1

make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2

___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu <mailto:Dyninst-api@cs.wisc.edu>
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api




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

[DynInst_API:] Compile error with master dyninst sources

[Jim Galarowicz]

Hi all,

I'm trying to build the master git version of dyninst, but I'm getting 
this error.


Has anyone else hit this compile error?

Thanks,

Jim G


[ 12%] Built target symLite
[ 17%] Built target instructionAPI
[ 17%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
/usr/global/tools/openspeedshop/oss-dev/openspeedshop-externals/BUILD/surface86/dyninst-20180810/symtabAPI/src/Object-elf.C: 
In member function 'void 
Dyninst::SymtabAPI::Object::parseLineInfo(Dyninst::SymtabAPI::LineInformation*)':
/usr/global/tools/openspeedshop/oss-dev/openspeedshop-externals/BUILD/surface86/dyninst-20180810/symtabAPI/src/Object-elf.C:4491:52: 
error: 'dwarf_next_lines' was not declared in this scope

 , , , )) == 0)
    ^
make[2]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o] Error 1
make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2

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

[DynInst_API:] Report an assertion with the latest git version of Dyninst

[Jim Galarowicz]

Hi all,

I can run OpenSpeedShop fine on this application with the 9.3.2 version 
of Dyninst and until recently the master git repository version too.


But, with the latest git master sources (as of yesterday morning) I'm 
seeing this assert.   The application is lulesh2.0.3 (mpi and openmp).


I can send the executable or any other information, if needed.

Thanks,

Jim G


mrnet_commnode: 
/tmp/jgalaro/spack-stage/spack-stage-Arx2ep/dyninst/symtabAPI/src/Object-elf.C:3546: 
int read_except_table_gcc3(const unsigned char*, mach_relative_info&, 
Dyninst::Elf_X_Shdr*, Dyninst::Elf_X_Shdr*, 
std::vector&): Assertion 
`low_pc_val==pc_begin_val' failed.


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

[DynInst_API:] libdwarf usage in Dyninst?

[Jim Galarowicz]

Hi all,

I'm trying to get a spack file change to the dyninst/package.py file 
through the spack review process.


My changes say that versions 9.3.2 and below use libdwarf and future 
versions use libdw.


Is that true?

Thanks,

Jim G

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

Re: [DynInst_API:] Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion `!"WARNING: overlapping try blocks\n"' failed.

[Jim Galarowicz]

Hi Sasha,

I received this feedback from the user:

   Hi Jim

   I was able to load this module and run the job, but I still got

   osscollect:
   
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/serrano-login1/dyninst-20180514frame/parseAPI/src/SymtabCodeSource.C:559:
   void Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks():
   Assertion `!"WARNING: overlapping try blocks\n"' failed.


So, the fix must be for a different issue, unfortunately.
Do you have any ideas for next steps?

Thanks,
Jim G

On 05/14/2018 01:47 PM, Sasha Da Rocha Pinheiro wrote:


Hi Jim,


we are trying to fix this issue. There is already a fix related to try 
blocks but it's not in the master branch, nor it has been tested yet.


Meanwhile, you may want to merge this commit locally and see if it 
fixes your problem. It's in the branch sasha/fix-eh-frame-parse.



I will test it and possibly merge to master but without further data I 
can't tell if it fixed your issue.


Let us know if you have any success.


Regards,

Sasha


*From:* Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of 
Xiaozhu Meng <mxz...@gmail.com>

*Sent:* Wednesday, May 9, 2018 5:29:58 PM
*To:* Jim Galarowicz
*Cc:* Don Maghrak; dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:] 
Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion 
`!"WARNING: overlapping try blocks\n"' failed.

Hi Jim,

In theory, try blocks should not overlap because otherwise how we know 
which catch block to handle the exception happened at the overlapping 
address.


So, it is more likely that there is a problem with the eh_frame 
parsing, which leads to wrong try block ranges.


For debugging, can you ask the user to run

objdump --dwarf=frames-interp PATH_TO_THE_TARGET

and sends us the output?

This command should output the correct exception handling information. 
We can then determine whether there is indeed overlapping try blocks 
or the parsing of try blocks is wrong.


Thanks,

--Xiaozhu





On Wed, May 9, 2018 at 3:06 PM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi all,

We have an abort that is showing a
Assertion `!"WARNING: overlapping try blocks\n"' failed. from
Dyninst.//
//The user stated that no core file was dropped.//

//The code is protected, so we don't have source code access or
execution access other than through the user.
Can anyone shed any light on what might cause overlapping try
block assertion?
This OSS version was built with a Nov 28, 2107 version of Dyninst.

Thanks,
Jim G


/
Processing raw data for alegra_3D_opt_team_tlcc2.x .../
/Processing processes and threads .../
/Processing performance data .../
/Processing symbols .../
/Resolving symbols for
/gpfs1/swbova/Alegra/trunk/bin/alegra_3D_opt_team_tlcc2.x/
/osscollect:

/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login3/dyninst-20171128/parseAPI/src/SymtabCodeSource.C:549:
void Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks():
Assertion `!"WARNING: overlapping try blocks\n"' failed./
//projects/OSS/cts1/osscbtf_v2.3.1.u3b.debug/bin/osspcsamp: line
1781: 98255 Aborted osscollect $topology_opt $cbtf_offline_opt
--program "$1" --collector $collector

/The application was built with these module enabled:

intel/17.0 gcc/4.9.3 openmpi-intel/1.10

with lines like this:

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009 -g …/
/mpif90 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/
/mpif77 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/

the link line is

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009    -o alegra_3D_opt_team_tlcc2.x.tmp Alegra/team/alegra.o
Alegra/team/Code_Coupling_Client.o Alegra/team/build_info.o
-L/gpfs1/swbova/Alegra/trunk/lib/3D_opt_team_tlcc2
-L/projects/alegra/TPL/CavityExpansion/1.0b/lib/opt_tlcc2
-L/projects/alegra/TPL/LegacyContact/1.0-n3/lib/opt_tlcc2
-L/projects/alegra/TPL/xyce/6.7/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sundials/2.6.1/install_opt_tlcc2/lib
-L/projects/alegra/TPL/spice/1.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/lambda/0.2.13/lib/opt_tlcc2
-L/projects/alegra/TPL/gnom3-fe/1.0.0/lib/opt_tlcc2
-L/projects/alegra/TPL/pff/2.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/dakota/6.6/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/acme/2.6c-n21/lib/opt_tlcc2 -L.
-L/projects/alegra/TPL/mesquite/0.9.6-n7/lib/opt_tlcc2
-L/projects/alegra/TPL/aprepro/2014_09_14/lib/opt_tlcc2
-L/projects/alegra/TPL/trilinos/2017_05_15/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/parmetis/4.0.3/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sculpt/15.4b-n9/lib/opt_tlcc2
-L/projects/al

Re: [DynInst_API:] Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion `!"WARNING: overlapping try blocks\n"' failed.

[Jim Galarowicz]

Hi Sasha,

Thanks!   I will build with the branch and have the user test again.

Thanks,

Jim G


On 05/14/2018 01:47 PM, Sasha Da Rocha Pinheiro wrote:


Hi Jim,


we are trying to fix this issue. There is already a fix related to try 
blocks but it's not in the master branch, nor it has been tested yet.


Meanwhile, you may want to merge this commit locally and see if it 
fixes your problem. It's in the branch sasha/fix-eh-frame-parse.



I will test it and possibly merge to master but without further data I 
can't tell if it fixed your issue.


Let us know if you have any success.


Regards,

Sasha


*From:* Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of 
Xiaozhu Meng <mxz...@gmail.com>

*Sent:* Wednesday, May 9, 2018 5:29:58 PM
*To:* Jim Galarowicz
*Cc:* Don Maghrak; dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:] 
Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion 
`!"WARNING: overlapping try blocks\n"' failed.

Hi Jim,

In theory, try blocks should not overlap because otherwise how we know 
which catch block to handle the exception happened at the overlapping 
address.


So, it is more likely that there is a problem with the eh_frame 
parsing, which leads to wrong try block ranges.


For debugging, can you ask the user to run

objdump --dwarf=frames-interp PATH_TO_THE_TARGET

and sends us the output?

This command should output the correct exception handling information. 
We can then determine whether there is indeed overlapping try blocks 
or the parsing of try blocks is wrong.


Thanks,

--Xiaozhu





On Wed, May 9, 2018 at 3:06 PM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi all,

We have an abort that is showing a
Assertion `!"WARNING: overlapping try blocks\n"' failed. from
Dyninst.//
//The user stated that no core file was dropped.//

//The code is protected, so we don't have source code access or
execution access other than through the user.
Can anyone shed any light on what might cause overlapping try
block assertion?
This OSS version was built with a Nov 28, 2107 version of Dyninst.

Thanks,
Jim G


/
Processing raw data for alegra_3D_opt_team_tlcc2.x .../
/Processing processes and threads .../
/Processing performance data .../
/Processing symbols .../
/Resolving symbols for
/gpfs1/swbova/Alegra/trunk/bin/alegra_3D_opt_team_tlcc2.x/
/osscollect:

/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login3/dyninst-20171128/parseAPI/src/SymtabCodeSource.C:549:
void Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks():
Assertion `!"WARNING: overlapping try blocks\n"' failed./
//projects/OSS/cts1/osscbtf_v2.3.1.u3b.debug/bin/osspcsamp: line
1781: 98255 Aborted osscollect $topology_opt $cbtf_offline_opt
--program "$1" --collector $collector

/The application was built with these module enabled:

intel/17.0 gcc/4.9.3 openmpi-intel/1.10

with lines like this:

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009 -g …/
/mpif90 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/
/mpif77 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/

the link line is

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009    -o alegra_3D_opt_team_tlcc2.x.tmp Alegra/team/alegra.o
Alegra/team/Code_Coupling_Client.o Alegra/team/build_info.o
-L/gpfs1/swbova/Alegra/trunk/lib/3D_opt_team_tlcc2
-L/projects/alegra/TPL/CavityExpansion/1.0b/lib/opt_tlcc2
-L/projects/alegra/TPL/LegacyContact/1.0-n3/lib/opt_tlcc2
-L/projects/alegra/TPL/xyce/6.7/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sundials/2.6.1/install_opt_tlcc2/lib
-L/projects/alegra/TPL/spice/1.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/lambda/0.2.13/lib/opt_tlcc2
-L/projects/alegra/TPL/gnom3-fe/1.0.0/lib/opt_tlcc2
-L/projects/alegra/TPL/pff/2.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/dakota/6.6/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/acme/2.6c-n21/lib/opt_tlcc2 -L.
-L/projects/alegra/TPL/mesquite/0.9.6-n7/lib/opt_tlcc2
-L/projects/alegra/TPL/aprepro/2014_09_14/lib/opt_tlcc2
-L/projects/alegra/TPL/trilinos/2017_05_15/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/parmetis/4.0.3/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sculpt/15.4b-n9/lib/opt_tlcc2
-L/projects/alegra/TPL/diom_spy/2.9/lib/opt_tlcc2
-L/projects/alegra/TPL/umfpack/5.1/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/y12m/1.0/lib/opt_tlcc2
-L/projects/alegra/TPL/freetype/1.3.1/lib/opt_tlcc2
-L/projects/alegra/TPL/slang/1.0/lib/opt_tlcc2
-L/projects/alegra/TPL/jpeg/6b_27-Mar-1998/lib/opt_tlcc2
-L/projects/alegra/TPL/image/2.4/lib/opt_tlcc2
-L/projects/alegra/TPL/mesaaux/3.2.1/lib/opt_tlcc2
-L/projects/alegra/

Re: [DynInst_API:] Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion `!"WARNING: overlapping try blocks\n"' failed.

[Jim Galarowicz]

Hi Xiaozhu,

I've sent the user a request.

Thanks much for the reply!

Jim G


On 05/09/2018 05:29 PM, Xiaozhu Meng wrote:

Hi Jim,

In theory, try blocks should not overlap because otherwise how we know 
which catch block to handle the exception happened at the overlapping 
address.


So, it is more likely that there is a problem with the eh_frame 
parsing, which leads to wrong try block ranges.


For debugging, can you ask the user to run

objdump --dwarf=frames-interp PATH_TO_THE_TARGET

and sends us the output?

This command should output the correct exception handling information. 
We can then determine whether there is indeed overlapping try blocks 
or the parsing of try blocks is wrong.


Thanks,

--Xiaozhu





On Wed, May 9, 2018 at 3:06 PM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi all,

We have an abort that is showing a
Assertion `!"WARNING: overlapping try blocks\n"' failed. from
Dyninst.//
//The user stated that no core file was dropped.//

//The code is protected, so we don't have source code access or
execution access other than through the user.
Can anyone shed any light on what might cause overlapping try
block assertion?
This OSS version was built with a Nov 28, 2107 version of Dyninst.

Thanks,
Jim G


/
Processing raw data for alegra_3D_opt_team_tlcc2.x .../
/Processing processes and threads .../
/Processing performance data .../
/Processing symbols .../
/Resolving symbols for
/gpfs1/swbova/Alegra/trunk/bin/alegra_3D_opt_team_tlcc2.x/
/osscollect:

/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login3/dyninst-20171128/parseAPI/src/SymtabCodeSource.C:549:
void Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks():
Assertion `!"WARNING: overlapping try blocks\n"' failed./
//projects/OSS/cts1/osscbtf_v2.3.1.u3b.debug/bin/osspcsamp: line
1781: 98255 Aborted                 osscollect $topology_opt
$cbtf_offline_opt --program "$1" --collector $collector

/The application was built with these module enabled:

intel/17.0 gcc/4.9.3 openmpi-intel/1.10

with lines like this:

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009 -g …/
/mpif90 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/
/mpif77 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/

the link line is

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable
15009    -o alegra_3D_opt_team_tlcc2.x.tmp Alegra/team/alegra.o
Alegra/team/Code_Coupling_Client.o Alegra/team/build_info.o
-L/gpfs1/swbova/Alegra/trunk/lib/3D_opt_team_tlcc2
-L/projects/alegra/TPL/CavityExpansion/1.0b/lib/opt_tlcc2
-L/projects/alegra/TPL/LegacyContact/1.0-n3/lib/opt_tlcc2
-L/projects/alegra/TPL/xyce/6.7/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sundials/2.6.1/install_opt_tlcc2/lib
-L/projects/alegra/TPL/spice/1.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/lambda/0.2.13/lib/opt_tlcc2
-L/projects/alegra/TPL/gnom3-fe/1.0.0/lib/opt_tlcc2
-L/projects/alegra/TPL/pff/2.1-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/dakota/6.6/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/acme/2.6c-n21/lib/opt_tlcc2 -L.
-L/projects/alegra/TPL/mesquite/0.9.6-n7/lib/opt_tlcc2
-L/projects/alegra/TPL/aprepro/2014_09_14/lib/opt_tlcc2
-L/projects/alegra/TPL/trilinos/2017_05_15/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/parmetis/4.0.3/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/sculpt/15.4b-n9/lib/opt_tlcc2
-L/projects/alegra/TPL/diom_spy/2.9/lib/opt_tlcc2
-L/projects/alegra/TPL/umfpack/5.1/inst_opt_tlcc2/lib
-L/projects/alegra/TPL/y12m/1.0/lib/opt_tlcc2
-L/projects/alegra/TPL/freetype/1.3.1/lib/opt_tlcc2
-L/projects/alegra/TPL/slang/1.0/lib/opt_tlcc2
-L/projects/alegra/TPL/jpeg/6b_27-Mar-1998/lib/opt_tlcc2
-L/projects/alegra/TPL/image/2.4/lib/opt_tlcc2
-L/projects/alegra/TPL/mesaaux/3.2.1/lib/opt_tlcc2
-L/projects/alegra/TPL/superludist/2.0/lib/opt_tlcc2
-L/projects/alegra/TPL/glu/3.2.1/lib/opt_tlcc2
-L/projects/alegra/TPL/mesa/3.2.1/lib/opt_tlcc2
-L/projects/alegra/TPL/nemesis/3.07-n3/lib/opt_tlcc2
-L/projects/alegra/TPL/exodus/4.68-n1/lib/opt_tlcc2
-L/projects/alegra/TPL/netcdf/4.3-snl1/inst_opt_tlcc2/lib -lutdem
-lqsem -lremesh_app -lconduction -lremesh -ltnburn -lphysics -lmhd
-lradiation -lkullimc -ltnburn -lphysics -lremap -linterface_recon
-lremesh -lhedp_physics -lmhd -linterface_recon -lremap -lkullimc
-lradiation -lCavityExpansion -lcircuit_intf -lcontact
-lhedp_matlibs -lcircuit -lxyce -lSandiaModels -lsundials_ida
-lsundials_nvecserial -lmatlibs -llambda -lmatlibs -lspice
-llambda -lgnom3-fe -lnevada -lpff -ldakota_src
-ldakota_src_fortran -loptpp -lpecos_src -lddace -lpsuade
-lsurfpack -lsurfpack_fortran -ljega -ljega_fe -lsoga -ljega
-ljega_fe

[DynInst_API:] Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion `!"WARNING: overlapping try blocks\n"' failed.

[Jim Galarowicz]

Hi all,

We have an abort that is showing a
Assertion `!"WARNING: overlapping try blocks\n"' failed. from Dyninst.//
//The user stated that no core file was dropped.//

//The code is protected, so we don't have source code access or 
execution access other than through the user.
Can anyone shed any light on what might cause overlapping try block 
assertion?

This OSS version was built with a Nov 28, 2107 version of Dyninst.

Thanks,
Jim G


/
Processing raw data for alegra_3D_opt_team_tlcc2.x .../
/Processing processes and threads .../
/Processing performance data .../
/Processing symbols .../
/Resolving symbols for 
/gpfs1/swbova/Alegra/trunk/bin/alegra_3D_opt_team_tlcc2.x/
/osscollect: 
/projects/OpenSpeedShop/jgalaro/openspeedshop-externals/BUILD/ghost-login3/dyninst-20171128/parseAPI/src/SymtabCodeSource.C:549: 
void Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion 
`!"WARNING: overlapping try blocks\n"' failed./
//projects/OSS/cts1/osscbtf_v2.3.1.u3b.debug/bin/osspcsamp: line 1781: 
98255 Aborted                 osscollect $topology_opt $cbtf_offline_opt 
--program "$1" --collector $collector


/The application was built with these module enabled:

intel/17.0 gcc/4.9.3 openmpi-intel/1.10

with lines like this:

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 
-g …/

/mpif90 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/
/mpif77 -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 …/

the link line is

/mpicxx -std=c++0x -O2 -axAVX -fp-model strict -ftz -diag-disable 15009 
   -o alegra_3D_opt_team_tlcc2.x.tmp Alegra/team/alegra.o 
Alegra/team/Code_Coupling_Client.o Alegra/team/build_info.o 
-L/gpfs1/swbova/Alegra/trunk/lib/3D_opt_team_tlcc2 
-L/projects/alegra/TPL/CavityExpansion/1.0b/lib/opt_tlcc2 
-L/projects/alegra/TPL/LegacyContact/1.0-n3/lib/opt_tlcc2 
-L/projects/alegra/TPL/xyce/6.7/inst_opt_tlcc2/lib 
-L/projects/alegra/TPL/sundials/2.6.1/install_opt_tlcc2/lib 
-L/projects/alegra/TPL/spice/1.1-n1/lib/opt_tlcc2 
-L/projects/alegra/TPL/lambda/0.2.13/lib/opt_tlcc2 
-L/projects/alegra/TPL/gnom3-fe/1.0.0/lib/opt_tlcc2 
-L/projects/alegra/TPL/pff/2.1-n1/lib/opt_tlcc2 
-L/projects/alegra/TPL/dakota/6.6/inst_opt_tlcc2/lib 
-L/projects/alegra/TPL/acme/2.6c-n21/lib/opt_tlcc2 -L. 
-L/projects/alegra/TPL/mesquite/0.9.6-n7/lib/opt_tlcc2 
-L/projects/alegra/TPL/aprepro/2014_09_14/lib/opt_tlcc2 
-L/projects/alegra/TPL/trilinos/2017_05_15/inst_opt_tlcc2/lib 
-L/projects/alegra/TPL/parmetis/4.0.3/inst_opt_tlcc2/lib 
-L/projects/alegra/TPL/sculpt/15.4b-n9/lib/opt_tlcc2 
-L/projects/alegra/TPL/diom_spy/2.9/lib/opt_tlcc2 
-L/projects/alegra/TPL/umfpack/5.1/inst_opt_tlcc2/lib 
-L/projects/alegra/TPL/y12m/1.0/lib/opt_tlcc2 
-L/projects/alegra/TPL/freetype/1.3.1/lib/opt_tlcc2 
-L/projects/alegra/TPL/slang/1.0/lib/opt_tlcc2 
-L/projects/alegra/TPL/jpeg/6b_27-Mar-1998/lib/opt_tlcc2 
-L/projects/alegra/TPL/image/2.4/lib/opt_tlcc2 
-L/projects/alegra/TPL/mesaaux/3.2.1/lib/opt_tlcc2 
-L/projects/alegra/TPL/superludist/2.0/lib/opt_tlcc2 
-L/projects/alegra/TPL/glu/3.2.1/lib/opt_tlcc2 
-L/projects/alegra/TPL/mesa/3.2.1/lib/opt_tlcc2 
-L/projects/alegra/TPL/nemesis/3.07-n3/lib/opt_tlcc2 
-L/projects/alegra/TPL/exodus/4.68-n1/lib/opt_tlcc2 
-L/projects/alegra/TPL/netcdf/4.3-snl1/inst_opt_tlcc2/lib -lutdem -lqsem 
-lremesh_app -lconduction -lremesh -ltnburn -lphysics -lmhd -lradiation 
-lkullimc -ltnburn -lphysics -lremap -linterface_recon -lremesh 
-lhedp_physics -lmhd -linterface_recon -lremap -lkullimc -lradiation 
-lCavityExpansion -lcircuit_intf -lcontact -lhedp_matlibs -lcircuit 
-lxyce -lSandiaModels -lsundials_ida -lsundials_nvecserial -lmatlibs 
-llambda -lmatlibs -lspice -llambda -lgnom3-fe -lnevada -lpff 
-ldakota_src -ldakota_src_fortran -loptpp -lpecos_src -lddace -lpsuade 
-lsurfpack -lsurfpack_fortran -ljega -ljega_fe -lsoga -ljega -ljega_fe 
-lmoga -lcport -lncsuopt -llhs -llhs_mods -llhs_mod -lfsudace 
-lsparsegrid -lconmin -lcolin -lscolib -lpebbl -linterfaces -l3po 
-lutilib -ltinyxml -lamplsolver -ldream -lnomad -lapproxnn -lutilities 
-leutils -lnidr -lacme -lzoltanitf -lphystools -lparser -lsnltools 
-lmesquite -laprepro -lunits -lRestart -ltoolkit -ltrilinoscouplings 
-lpiro -lrythmos -lmuelu-adapters -lmuelu-interface -lmuelu -llocathyra 
-llocaepetra -llocalapack -lloca -lnoxepetra -lnoxlapack -lnox 
-lintrepid -lstratimikos -lstratimikosbelos -lstratimikosaztecoo 
-lstratimikosamesos -lstratimikosml -lstratimikosifpack 
-lifpack2-adapters -lifpack2 -lanasazitpetra -lModeLaplace 
-lanasaziepetra -lanasazi -lamesos2 -lbelostpetra -lbelosepetra -lbelos 
-lml -lifpack -lzoltan2 -lpamgen_extras -lpamgen -lamesos 
-lgaleri-xpetra -lgaleri-epetra -laztecoo -lisorropia -lxpetra-sup 
-lxpetra -lthyratpetra -lthyraepetraext -lthyraepetra -lthyracore 
-lthyratpetra -lthyraepetraext -lthyraepetra -lthyracore -lepetraext 
-ltrilinosss -ltpetraext -ltpetrainout -ltpetra -lkokkostsqr 
-ltpetraclassiclinalg -ltpetraclassicnodeapi -ltpetraclassic -ltpetraext 

Re: [DynInst_API:] codeCoverage build issue with latest master branch git version of Dyninst

[Jim Galarowicz]

/localhost.localdomain/dyninst-9.3.3/common

-- Processing dependent target instructionAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/instructionAPI

-- Processing dependent target parseAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI

CMake Error at examples/CMakeLists.txt:12 (file):
  file COPY cannot find
"/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/unstrip/ddb.db".


CMake Error at examples/CMakeLists.txt:13 (file):
  file COPY cannot find
"/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/unstrip/params.db".


CMake Error at examples/CMakeLists.txt:14 (file):
  file COPY cannot find
"/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/unstrip/unistd.db".


-- Building dyninstAPI...
-- Processing dependent target common...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/common

-- Processing dependent target instructionAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/instructionAPI

-- Processing dependent target stackwalk...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/stackwalk

-- Processing dependent target pcontrol...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/proccontrol

-- Processing dependent target patchAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/patchAPI

-- Processing dependent target parseAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI

-- Processing dependent target symtabAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/symtabAPI

-- Building dynC_API...
-- Processing dependent target dyninstAPI...
-- Found dependency location 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/dyninstAPI

-- Configuring DyninstAPI_RT
-- Configuring RT library
-- The C compiler identification is GNU 7.2.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- -- Input platform: x86_64-unknown-linux2.4
-- Set arch and platform based definitions
-- Options set
-- Set optimization flags
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
-- dyninstAPI RT library SOVERSION: 9.3
-- dyninstAPI RT library LIBVERSION: 9.3.2
-- Checking for 32-bit runtime library...
-- Performing Test CHECK_RT_LIB_32
-- Performing Test CHECK_RT_LIB_32 - Failed
-- Disabling 32-bit runtime library; change BUILD_RTLIB_32 to ON and 
install 32-bit build environment to enable

-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/dyninstAPI_RT

-- Could NOT find LATEX (missing:  LATEX_COMPILER)
-- LaTeX not found
-- Adding Unix-specific dependencies
-- Added libdwarf_imp and libelf_imp dependencies
-- Configuring incomplete, errors occurred!
See also 
"/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/CMakeFiles/CMakeOutput.log".

make: *** [Makefile:798: cmake_check_build_system] Error 1
[jeg@localhost dyninst-9.3.3]$

On 04/13/2018 09:20 AM, Xiaozhu Meng wrote:

Hi Jim,

I just recompiled the master branch from github. I saw the same 
warning, but not the error. Can you try delete your existing cmake 
cache file and then re-configure the cmake?


Thanks,

--Xiaozhu

On Fri, Apr 13, 2018 at 8:53 AM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi all,

I'm trying to build the latest git master branch version of
dyninst and I'm getting these build errors in codeCoverage.

Has anyone else seen this?   I'm using the same cmake variables
that I did for 9.3.2, maybe that is the problem?

Thanks,

Jim G

[ 94%] Built target Inst
Scanning dependencies of target cfg_to_dot
[ 94%] Building CXX object
examples/CMakeFiles/cfg_to_dot.dir/__/parseAPI/doc/example.cc.o

/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI/doc/example.cc:
In function ‘int main(int, char**)’:

/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI/doc/example.cc:19:14:
warning: unused parameter ‘argc’ [-Wunused-parameter]
 int main(int argc, char * argv[])
  ^~~~
Linking CXX executable cfg_to_dot
[ 94

[DynInst_API:] codeCoverage build issue with latest master branch git version of Dyninst

[Jim Galarowicz]

Hi all,

I'm trying to build the latest git master branch version of dyninst and 
I'm getting these build errors in codeCoverage.


Has anyone else seen this?   I'm using the same cmake variables that I 
did for 9.3.2, maybe that is the problem?


Thanks,

Jim G

[ 94%] Built target Inst
Scanning dependencies of target cfg_to_dot
[ 94%] Building CXX object 
examples/CMakeFiles/cfg_to_dot.dir/__/parseAPI/doc/example.cc.o
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI/doc/example.cc: 
In function ‘int main(int, char**)’:
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/parseAPI/doc/example.cc:19:14: 
warning: unused parameter ‘argc’ [-Wunused-parameter]

 int main(int argc, char * argv[])
  ^~~~
Linking CXX executable cfg_to_dot
[ 94%] Built target cfg_to_dot
Scanning dependencies of target codeCoverage
[ 95%] Building CXX object 
examples/CMakeFiles/codeCoverage.dir/codeCoverage/codeCoverage.C.o
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C: 
In function ‘int main(int, char**)’:
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:267:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "initCoverage");
    ^~
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:269:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "registerFunc");
    ^~
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:271:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "incFuncCoverage");
    ^
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:273:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "registerBB");
    ^~~~
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:275:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "incBBCoverage");
    ^~~
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:277:44: 
warning: cast from type ‘const char*’ to type ‘char*’ casts away 
qualifiers [-Wcast-qual]

 findFuncByName (appImage, (char *) "exitCoverage");
    ^~
/home/jeg/openspeedshop-externals/BUILD/localhost.localdomain/dyninst-9.3.3/examples/codeCoverage/codeCoverage.C:290:20: 
warning: variable ‘defaultModule’ set but not used 
[-Wunused-but-set-variable]

 BPatch_module *defaultModule;
    ^
Linking CXX executable codeCoverage
/usr/bin/ld: cannot open output file codeCoverage: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [examples/CMakeFiles/codeCoverage.dir/build.make:93: 
examples/codeCoverage] Error 1
make[1]: *** [CMakeFiles/Makefile2:1502: 
examples/CMakeFiles/codeCoverage.dir/all] Error 2

make: *** [Makefile:117: all] Error 2
[  0%] Building DyninstRT


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

Re: [DynInst_API:] DyninstAPI: Compile error while building top of tree

[Jim Galarowicz]

I will try on the LLNL systems.

Here is the uname -a output for this cluster.

[jeg@p8-node OpenSpeedShop_ROOT]$ uname -a
Linux p8-node.ddd.com 3.10.0-514.21.2.el7.ppc64le #1 SMP Tue Jun 20 
16:35:48 GMT 2017 ppc64le ppc64le ppc64le GNU/Linux


On 10/03/2017 03:37 PM, Bill Williams wrote:

Yeah. And it is what I'd expect, so why isn't it matching? Weird.

You should be able to pass -dcap_dwarf as an additional CFLAG/CXXFLAG at 
configure time to get around this; however, does this reproduce on any of the 
LLNL ppc64 systems?

--bw

From: Jim Galarowicz <j...@krellinst.org>
Sent: Tuesday, October 3, 2017 3:30 PM
To: Bill Williams; dyninst-api@cs.wisc.edu
Cc: j...@krellinst.org
Subject: Re: [DynInst_API:] DyninstAPI: Compile error while building top of tree

Is this what you need?

-- -- Input platform: ppc64_linux


-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: ppc64_linux
-- Found LibDwarf:
/home/jeg/openss/power/krellroot_v2.3.1.latest/lib/libdw.so
-- Found LibElf:
/home/jeg/openss/power/krellroot_v2.3.1.latest/lib/libelf.so
-- Found libiberty: /usr/lib64/libiberty.a
-- Using libiberty /usr/lib64/libiberty.a
-- Found Thread_Db: /usr/lib64/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- Boost version: 1.53.0
-- Found the following Boost libraries:
--   thread
--   system
--   date_time
-- Boost includes: /usr/include
-- Boost library dirs: /usr/lib64
-- Boost thread library: /usr/lib64/libboost_thread-mt.so
-- Boost libraries:
/usr/lib64/libboost_thread-mt.so;/usr/lib64/libboost_system-mt.so;/usr/lib64/libboost_date_time-mt.so
-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support for "__func__": works
-- Checking C++11 support for "auto"
-- Checking C++11 support for "auto": works
-- Checking C++11 support for "auto_ret_type"
-- Checking C++11 support for "auto_ret_type": works
-- Checking C++11 support for "class_override_final"
-- Checking C++11 support for "class_override_final": not supported
-- Checking C++11 support for "constexpr"
-- Checking C++11 support for "constexpr": works
-- Checking C++11 support for "cstdint"
-- Checking C++11 support for "cstdint": works
-- Checking C++11 support for "decltype"
-- Checking C++11 support for "decltype": works
-- Checking C++11 support for "initializer_list"
-- Checking C++11 support for "initializer_list": works
-- Checking C++11 support for "lambda"
-- Checking C++11 support for "lambda": works
-- Checking C++11 support for "long_long"
-- Checking C++11 support for "long_long": works
-- Checking C++11 support for "nullptr"
-- Checking C++11 support for "nullptr": works
-- Checking C++11 support for "regex"
-- Checking C++11 support for "regex": not supported
-- Checking C++11 support for "rvalue-references"
-- Checking C++11 support for "rvalue-references": works
-- Checking C++11 support for "sizeof_member"
-- Checking C++11 support for "sizeof_member": works
-- Checking C++11 support for "static_assert"
-- Checking C++11 support for "static_assert": works
-- Checking C++11 support for "variadic_templates"
-- Checking C++11 support for "variadic_templates": works
-- C++11 support found, required flags are: -std=c++11
-- Enabling ThreadDB support
-- Set arch and platform based definitions
-- Found g++, enabling -fvisibility=hidden
-- Options set
-- Set optimization flags
-- cotire 1.7.8 loaded.
-- Building common...
-- Processing dependent target /usr/lib64/libiberty.a...
-- CXX target common cotired without unity build.
-- Building dynElf...
-- Processing dependent target
/home/jeg/openss/power/krellroot_v2.3.1.latest/lib/libelf.so...
-- CXX target dynElf cotired without unity build and precompiled header.
Too few applicable sources.
-- Building dynDwarf...
-- Processing dependent target dynElf...
-- Found dependency location
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/elf
-- Processing dependent target common...
-- Found dependency location
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/common
-- Processing dependent target
/home/jeg/open

Re: [DynInst_API:] DyninstAPI: Compile error while building top of tree

[Jim Galarowicz]

g RT library
-- The C compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- -- Input platform: ppc64_linux
-- Set arch and platform based definitions
-- Options set
-- Set optimization flags
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc
-- dyninstAPI RT library SOVERSION: 9.3
-- dyninstAPI RT library LIBVERSION: 9.3.2
-- Checking for 32-bit runtime library...
-- Performing Test CHECK_RT_LIB_32
-- Performing Test CHECK_RT_LIB_32 - Failed
-- Disabling 32-bit runtime library; change BUILD_RTLIB_32 to ON and 
install 32-bit build environment to enable

-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/dyninstAPI_RT

-- LaTeX not found
-- Adding Unix-specific dependencies
-- Added libdwarf_imp and libelf_imp dependencies
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:


On 10/03/2017 03:21 PM, Bill Williams wrote:

...okay, on further examination this means that cap_dwarf is somehow missing 
from your platform defines. What's $PLATFORM coming out of CMake? Any linux 
should have cap_dwarf enabled...

From: Jim Galarowicz <j...@krellinst.org>
Sent: Tuesday, October 3, 2017 2:16 PM
To: Bill Williams; dyninst-api@cs.wisc.edu
Cc: j...@krellinst.org
Subject: Re: [DynInst_API:] DyninstAPI: Compile error while building top of tree

Hi Bill,

I made this change, but it didn't seem to help with the compile error.

diff --git a/cmake/shared.cmake b/cmake/shared.cmake
index 0b49ccd..41bc676 100644
--- a/cmake/shared.cmake
+++ b/cmake/shared.cmake
@@ -99,7 +99,7 @@ include (${DYNINST_ROOT}/cmake/options.cmake)
   include (${DYNINST_ROOT}/cmake/optimization.cmake)

   # Check for cotire-gcc compatibility
-set(USE_COTIRE true)
+set(USE_COTIRE false)
   IF(CMAKE_COMPILER_IS_GNUCC)
   execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
   string(REGEX MATCHALL "[0-9]+" GCC_VERSION_COMPONENTS ${GCC_VERSION})

Jim G

On 10/03/2017 01:54 PM, Bill Williams wrote:

First step here is disabling cotire; it's great when it works but it seems to 
have gotten very brittle on HPC systems. IIRC top of tree should have that as 
an explicit cache variable. If not I'll make sure I push a patch up...

If that doesn't do the trick it should just be a missing include I'd think.

From: Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of Jim Galarowicz 
<j...@krellinst.org>
Sent: Tuesday, October 3, 2017 1:47 PM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] DyninstAPI: Compile error while building top of tree

Hi all,

Just tried to build the top of tree (from a few minutes ago). I'm seeing
this error on a power 8 cluster.

Thanks,

Jim G


19%] Building CXX object
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
In file included from
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/cotire/symtabAPI_CXX_prefix.cxx:22:0,
from
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/cotire/symtabAPI_CXX_prefix.hxx:4:
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/src/Object-elf.C:
In function ‘int read_except_table_gcc3(Dwarf*, mach_relative_info&,
Dyninst::Elf_X_Shdr*, Dyninst::Elf_X_Shdr*,
std::vector&)’:
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/src/Object-elf.C:3418:12:
error: ‘DW_CIE_ID_64’ was not declared in this scope
if(dwarf_cfi_cie_p())
   ^
make[2]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o] Error 1
make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2

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


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

[DynInst_API:] DyninstAPI: Compile error while building top of tree

[Jim Galarowicz]

Hi all,

Just tried to build the top of tree (from a few minutes ago). I'm seeing 
this error on a power 8 cluster.


Thanks,

Jim G


 19%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
In file included from 
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/cotire/symtabAPI_CXX_prefix.cxx:22:0,
 from 
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/cotire/symtabAPI_CXX_prefix.hxx:4:
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/src/Object-elf.C: 
In function ‘int read_except_table_gcc3(Dwarf*, mach_relative_info&, 
Dyninst::Elf_X_Shdr*, Dyninst::Elf_X_Shdr*, 
std::vector&)’:
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20171003/symtabAPI/src/Object-elf.C:3418:12: 
error: ‘DW_CIE_ID_64’ was not declared in this scope

 if(dwarf_cfi_cie_p())
    ^
make[2]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o] Error 1
make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2

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

Re: [DynInst_API:] Dyninst compile errors with top of tree on Power 8

[Jim Galarowicz]

Hi Bill,

I'm not familiar with libdw - is that source in the elfutils tree?
All internet search point back to the elfutils source.

Thanks for the reply!
Jim G
On 09/05/2017 09:25 AM, Bill Williams wrote:

The latest master now uses libdw over libdwarf; I see an official announcement 
of this didn't go out with the merge. Same set of CMake flags, just point to 
libdw and ditch libdwarf.

--bw


From: Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of Jim Galarowicz 
<j...@krellinst.org>
Sent: Tuesday, September 5, 2017 11:20 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] Dyninst compile errors with top of tree on Power 8

Hi all,

I downloaded the latest dyninst git tree sources this weekend and tried
to build on a power 8 cluster.
I'm using libdwarf 20170416 and elfutils-0.168, but I'm getting these
compile errors with
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC).

Are there any new libdwarf or elfutils version requirements?

Thanks,
Jim G


/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:426:6:
warning: unused parameter ‘high’ [-Wunused-parameter]
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:426:6:
warning: unused parameter ‘err_result’ [-Wunused-parameter]
[ 13%] Building CXX object dwarf/CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o
Linking CXX shared library libdynDwarf.so
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegAtFrame_aux(unsigned
long, Dwarf_Frame_s*, unsigned short, Dyninst::MachRegister,
Dyninst::DwarfDyninst::DwarfResult&, unsigned long&,
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:308:
undefined reference to `dwarf_frame_register'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:320:
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:312:
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function
`Dyninst::DwarfDyninst::DwarfFrameParser::getDwarfReg(Dyninst::MachRegister,
Dwarf_Frame_s*, unsigned short&, Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:487:
undefined reference to `dwarf_frame_info'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function
`Dyninst::DwarfDyninst::DwarfFrameParser::setupFdeData()':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:402:
undefined reference to `dwarf_getcfi'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:409:
undefined reference to `dwarf_getelf'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:410:
undefined reference to `dwarf_getcfi_elf'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegAtFrame(unsigned long,
Dyninst::MachRegister, Dyninst::DwarfDyninst::DwarfResult&,
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:234:
undefined reference to `dwarf_cfi_addrframe'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:237:
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:241:
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegsForFunction(std::pair, Dyninst::MachRegister,
std::vector<Dyninst::VariableLocation,
std::allocator >&,
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:182:
undefined reference to `dwarf_cfi_addrframe'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:186:
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:190:
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o: In function
`Dyninst::DwarfDyninst::DwarfHandle::init_dbg()':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:106:
undefined reference to `dwarf_begin_elf'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:115:
undefined reference to `dwarf_begin_elf'
CMakeFiles/

[DynInst_API:] Dyninst compile errors with top of tree on Power 8

[Jim Galarowicz]

Hi all,

I downloaded the latest dyninst git tree sources this weekend and tried 
to build on a power 8 cluster.
I'm using libdwarf 20170416 and elfutils-0.168, but I'm getting these 
compile errors with

gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC).

Are there any new libdwarf or elfutils version requirements?

Thanks,
Jim G


/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:426:6: 
warning: unused parameter ‘high’ [-Wunused-parameter]
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:426:6: 
warning: unused parameter ‘err_result’ [-Wunused-parameter]

[ 13%] Building CXX object dwarf/CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o
Linking CXX shared library libdynDwarf.so
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function 
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegAtFrame_aux(unsigned 
long, Dwarf_Frame_s*, unsigned short, Dyninst::MachRegister, 
Dyninst::DwarfDyninst::DwarfResult&, unsigned long&, 
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:308: 
undefined reference to `dwarf_frame_register'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:320: 
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:312: 
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function 
`Dyninst::DwarfDyninst::DwarfFrameParser::getDwarfReg(Dyninst::MachRegister, 
Dwarf_Frame_s*, unsigned short&, Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:487: 
undefined reference to `dwarf_frame_info'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function 
`Dyninst::DwarfDyninst::DwarfFrameParser::setupFdeData()':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:402: 
undefined reference to `dwarf_getcfi'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:409: 
undefined reference to `dwarf_getelf'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:410: 
undefined reference to `dwarf_getcfi_elf'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function 
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegAtFrame(unsigned long, 
Dyninst::MachRegister, Dyninst::DwarfDyninst::DwarfResult&, 
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:234: 
undefined reference to `dwarf_cfi_addrframe'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:237: 
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:241: 
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfFrameParser.C.o: In function 
`Dyninst::DwarfDyninst::DwarfFrameParser::getRegsForFunction(std::pairlong, unsigned long>, Dyninst::MachRegister, 
std::vector&, 
Dyninst::DwarfDyninst::FrameErrors_t&)':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:182: 
undefined reference to `dwarf_cfi_addrframe'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:186: 
undefined reference to `dwarf_frame_info'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfFrameParser.C:190: 
undefined reference to `dwarf_frame_cfa'
CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o: In function 
`Dyninst::DwarfDyninst::DwarfHandle::init_dbg()':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:106: 
undefined reference to `dwarf_begin_elf'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:115: 
undefined reference to `dwarf_begin_elf'
CMakeFiles/dynDwarf.dir/src/dwarfHandle.C.o: In function 
`Dyninst::DwarfDyninst::DwarfHandle::~DwarfHandle()':
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:240: 
undefined reference to `dwarf_end'
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dyninst-20170903/dwarf/src/dwarfHandle.C:242: 
undefined reference to `dwarf_end'

collect2: error: ld returned 1 exit status
make[2]: *** [dwarf/libdynDwarf.so.9.3.2] Error 1
make[1]: *** [dwarf/CMakeFiles/dynDwarf.dir/all] Error 2
make: *** [all] Error 2
[  0%] Building DyninstRT
[ 50%] Built target dyninstAPI_RT
[100%] Built target dyninstAPI_RT_static
[  0%] Built target DyninstRT
[ 

Re: [DynInst_API:] Dyninst LineInformation interface change between 9.2.0 and 9.3.2

[Jim Galarowicz]

Hi Bill,

I found it - sorry for the bother.

git clone https://github.com/dyninst/testsuite.git

Jim G


On 05/17/2017 04:22 PM, Jim Galarowicz wrote:

Hi Bill,

Thanks!   But, where is the test-suite?  Is it a separate download 
now?  I couldn't find it on your downloads area.


Thanks
Jim G

On 05/17/2017 02:26 PM, Bill Williams wrote:
The test suite is always good for example code (test_line_info in the 
symtab tests). But what you want, in essence, are the Statement class 
and its filename/line number methods. (This has the benefit of being 
more readable code, as well. I hate pointless tuples when you can use 
meaningful names instead...)


I don't remember if we officially deprecated LineNoTuple, but it's 
been treated as deprecated for quite a few versions, and you should 
expect it to go away in favor of Statement when 10.0 is official.


--bw


From: Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of Jim 
Galarowicz <j...@krellinst.org>

Sent: Wednesday, May 17, 2017 3:29 PM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] Dyninst LineInformation interface change 
between9.2.0 and 9.3.2


Hi Bill, all,

We are trying to upgrade from Dyninst-9.2.0 to Dyninst-9.3.2 - forced 
really because of Power 8 related Dyninst aborts with 9.2.0 that we 
hope are fixed in the newer version.


We have a snippet of code that gets line number information, that now 
does not compile with 9.3.2, but does with 9.2.0.


The snippet of code is:
428
429for(unsigned i = 0; i< mods.size();i++) {
430
431LineInformation *lineInformation = 
mods[i]->getLineInformation();

432if(lineInformation) {
433LineInformation::const_iterator iter = 
lineInformation->begin();

434for(;iter!=lineInformation->end();iter++) {
435const std::pair<Offset, Offset> range = iter->first;
436LineNoTuple line = iter->second;
437KrellInstitute::Core::Address b(range.first);
438KrellInstitute::Core::Address e(range.second);
439// DEBUG
440#ifndef NDEBUG
441if(is_debug_symtabapi_symbols_enabled) {
442output << "SymtabAPISymbols::getAllSymbols: 
ADDING STATEMENT " << b << ":" << e
443<<" " << line.first << ":" << line.second  << 
std::endl;

444}
445#endif
446 st.addStatement(b,e,line.first,line.second,line.column);

The compile errors:

home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp: In member function 
‘void KrellInstitute::Core::SymtabAPISymbols::getAllSymbols(const 
KrellInstitute::Core::LinkedObjectEntry&, 
KrellInstitute::Core::SymbolTable&)’:
/home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp:435:49: error: 
request for member ‘first’ in 
‘*((boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*, 
std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, 
Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*, 
std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, 
boost::iterator<std::bidirectional_iterator_tag, 
Dyninst::SymtabAPI::Statement*, long int, 
Dyninst::SymtabAPI::Statement* const*, Dyninst::SymtabAPI::Statement* 
const&> > >*)(& iter))->boost::dereferenceable<T, P, 
B>::operator-><boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*, 
std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, 
Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*, 
std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, 
boost::iterator<std::bidirectional_iterator_tag, 
Dyninst::SymtabAPI::Statement*, long int, 
Dyninst::SymtabAPI::Statement* const*, 

Re: [DynInst_API:] Dyninst LineInformation interface change between 9.2.0 and 9.3.2

[Jim Galarowicz]

Hi Bill,

Thanks!   But, where is the test-suite?  Is it a separate download now?  
I couldn't find it on your downloads area.


Thanks
Jim G

On 05/17/2017 02:26 PM, Bill Williams wrote:

The test suite is always good for example code (test_line_info in the symtab 
tests). But what you want, in essence, are the Statement class and its 
filename/line number methods. (This has the benefit of being more readable 
code, as well. I hate pointless tuples when you can use meaningful names 
instead...)

I don't remember if we officially deprecated LineNoTuple, but it's been treated 
as deprecated for quite a few versions, and you should expect it to go away in 
favor of Statement when 10.0 is official.

--bw


From: Dyninst-api <dyninst-api-boun...@cs.wisc.edu> on behalf of Jim Galarowicz 
<j...@krellinst.org>
Sent: Wednesday, May 17, 2017 3:29 PM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] Dyninst LineInformation interface change between
9.2.0 and 9.3.2

Hi Bill, all,

We are trying to upgrade from Dyninst-9.2.0 to Dyninst-9.3.2 - forced really 
because of Power 8 related Dyninst aborts with 9.2.0 that we hope are fixed in 
the newer version.

We have a snippet of code that gets line number information, that now does not 
compile with 9.3.2, but does with 9.2.0.

The snippet of code is:
428
429for(unsigned i = 0; i< mods.size();i++) {
430
431LineInformation *lineInformation = mods[i]->getLineInformation();
432if(lineInformation) {
433LineInformation::const_iterator iter = 
lineInformation->begin();
434for(;iter!=lineInformation->end();iter++) {
435const std::pair<Offset, Offset> range = iter->first;
436LineNoTuple line = iter->second;
437KrellInstitute::Core::Address b(range.first);
438KrellInstitute::Core::Address e(range.second);
439// DEBUG
440#ifndef NDEBUG
441if(is_debug_symtabapi_symbols_enabled) {
442output << "SymtabAPISymbols::getAllSymbols: ADDING STATEMENT " << b << 
":" << e
443<<" " << line.first << ":" << line.second  << std::endl;
444}
445#endif
446st.addStatement(b,e,line.first,line.second,line.column);

The compile errors:

home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp: In member function ‘void 
KrellInstitute::Core::SymtabAPISymbols::getAllSymbols(const 
KrellInstitute::Core::LinkedObjectEntry&, KrellInstitute::Core::SymbolTable&)’:
/home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp:435:49: error: request for member ‘first’ in 
‘*((boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*,
 std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*,
 std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, boost::iterator<std::bidirectional_iterator_tag, Dyninst::SymtabAPI::Statement*, long int, Dyninst::SymtabAPI::Statement* const*, Dyninst::SymtabAPI::Statement* const&> > >*)(& 
iter))->boost::dereferenceable<T, P, 
B>::operator-><boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*,
 std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<Dyninst::SymtabAPI::Statement*,
 std::allocator<Dyninst::SymtabAPI::Statement*> > > > > >, boost::iterator<std::bidirectional_iterator_tag, Dyninst::SymtabAPI::Statement*, long int, Dyninst::SymtabAPI::Statement* const*, Dyninst::SymtabAPI::Statement* const&> > >()’, which is of 
pointer type ‘Dyninst::SymtabAPI::Statement* const’ (maybe you meant to use ‘->’ ?)
  

[DynInst_API:] Dyninst LineInformation interface change between 9.2.0 and 9.3.2

[Jim Galarowicz]

Hi Bill, all,

We are trying to upgrade from Dyninst-9.2.0 to Dyninst-9.3.2 - forced 
really because of Power 8 related Dyninst aborts with 9.2.0 that we hope 
are fixed in the newer version.


We have a snippet of code that gets line number information, that now 
does not compile with 9.3.2, but does with 9.2.0.


The snippet of code is:
   428
   429for(unsigned i = 0; i< mods.size();i++) {
   430
   431LineInformation *lineInformation = 
mods[i]->getLineInformation();

   432if(lineInformation) {
   433LineInformation::const_iterator iter = 
lineInformation->begin();

   434for(;iter!=lineInformation->end();iter++) {
*   435const std::pair range = iter->first;**
**   436LineNoTuple line = iter->second;*
   437KrellInstitute::Core::Address b(range.first);
   438KrellInstitute::Core::Address e(range.second);
   439// DEBUG
   440#ifndef NDEBUG
   441if(is_debug_symtabapi_symbols_enabled) {
   442output << "SymtabAPISymbols::getAllSymbols: 
ADDING STATEMENT " << b << ":" << e
   443<<" " << line.first << ":" << line.second  << 
std::endl;

   444}
   445#endif
   446 st.addStatement(b,e,line.first,line.second,line.column);

The compile errors:

home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp: In member function 
‘void KrellInstitute::Core::SymtabAPISymbols::getAllSymbols(const 
KrellInstitute::Core::LinkedObjectEntry&, 
KrellInstitute::Core::SymbolTable&)’:
/home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp:435:49: error: 
request for member ‘first’ in 
‘*((boost::dereferenceable > > > > >, 
Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable > > > > >, 
boost::iterator > >*)(& 
iter))->boost::dereferenceable::operator-> > > > > >, 
Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable > > > > >, 
boost::iterator > >()’, which is of 
pointer type ‘Dyninst::SymtabAPI::Statement* const’ (maybe you meant to 
use ‘->’ ?)

   const std::pair range = iter->first;
 ^
/home/jeg/cbtf-krell/core/src/SymtabAPISymbols.cpp:436:28: error: 
request for member ‘second’ in 
‘*((boost::dereferenceable > > > > >, 
Dyninst::SymtabAPI::Statement* const*, 
boost::decrementable > > > > >, 
boost::iterator > >*)(& 
iter))->boost::dereferenceable

[DynInst_API:] Compile error with Intel 15 on Cray (Edison at NERSC)

[Jim Galarowicz]

Hi Bill, all,

I'm seeing this compile error with the default 9.2.0 version using Intel 
15 compiler on Edison at NERSC.


> icc --version
icc (ICC) 15.0.1 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

jgalaro@edison05:/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT> 
which icc

/opt/intel/composer_xe_2015.1.133/bin/intel64/icc


[  9%] Building CXX object common/CMakeFiles/common.dir/src/MachSyscall.C.o
[  9%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/BUILD/edison05/dyninst-9.2.0/common/src/linuxKludges.C(1018): 
error: no instance of constructor "std::basic_ifstream<_CharT, 
_Traits>::basic_ifstream [with _CharT=char, 
_Traits=std::char_traits]" matches the argument list
argument types are: (std::basic_string)

 std::ifstream maps_file(maps_filename.str());
 ^

compilation aborted for 
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/BUILD/edison05/dyninst-9.2.0/common/src/linuxKludges.C 
(code 2)

make[2]: *** [common/CMakeFiles/common.dir/src/linuxKludges.C.o] Error 2
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2


*Full build output:*

/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/BUILD/edison05 
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/BUILD/edison05/dyninst-9.2.0 
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/BUILD/edison05 
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT
checking for 
/project/projectdirs/m888/jgalaro/OpenSpeedShop_ROOT/SOURCES/dyninst-9.2.0.patch

-- The C compiler identification is Intel 15.0.1.20141023
-- The CXX compiler identification is Intel 15.0.1.20141023
-- Check for working C compiler: 
/opt/intel/composer_xe_2015.1.133/bin/intel64/icc
-- Check for working C compiler: 
/opt/intel/composer_xe_2015.1.133/bin/intel64/icc -- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/opt/intel/composer_xe_2015.1.133/bin/intel64/icpc
-- Check for working CXX compiler: 
/opt/intel/composer_xe_2015.1.133/bin/intel64/icpc -- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: x86_64-unknown-linux2.4
-- Found LibElf: 
/project/projectdirs/m888/jgalaro/openss/edison/krellroot_v2.2.4intel/compute/lib64/libelf.so 

-- Found LibDwarf: 
/project/projectdirs/m888/jgalaro/openss/edison/krellroot_v2.2.4intel/compute/lib64/libdwarf.so 

-- Found libiberty: 
/project/projectdirs/m888/jgalaro/openss/edison/krellroot_v2.2.4intel/compute/lib64/libiberty_pic.a
-- Using libiberty 
/project/projectdirs/m888/jgalaro/openss/edison/krellroot_v2.2.4intel/compute/lib64/libiberty_pic.a

-- Found Thread_Db: /usr/lib64/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- Boost version: 1.59.0
-- Found the following Boost libraries:
--   thread
--   system
-- Boost includes: /usr/common/software/boost/1.59/intel/include
-- Boost library dirs: /usr/common/software/boost/1.59/intel/lib
-- Boost thread library: 
/usr/common/software/boost/1.59/intel/lib/libboost_thread.so
-- Boost libraries: 
/usr/common/software/boost/1.59/intel/lib/libboost_thread.so;/usr/common/software/boost/1.59/intel/lib/libboost_system.so

-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support for "__func__": works
-- Checking C++11 support for "auto"
-- Checking C++11 support for "auto": works
-- Checking C++11 support for "auto_ret_type"
-- Checking C++11 support for "auto_ret_type": works
-- Checking C++11 support for "class_override_final"
-- Checking C++11 support for "class_override_final": not supported
-- Checking C++11 support for "constexpr"
-- Checking C++11 support for "constexpr": works
-- Checking C++11 support for "cstdint"
-- Checking C++11 support for "cstdint": works
-- Checking C++11 support for "decltype"
-- Checking C++11 support for "decltype": works
-- Checking C++11 support for "initializer_list"
-- Checking C++11 support for "initializer_list": not supported
-- Checking C++11 support for "lambda"
-- Checking C++11 support for "lambda": works
-- Checking C++11 support for "long_long"
-- Checking C++11 support for "long_long": works
-- Checking C++11 support for "nullptr"
-- Checking C++11 support for "nullptr": works
-- Checking C++11 support for "regex"
-- Checking C++11 support for "regex": not supported
-- Checking C++11 support for "rvalue-references"
-- Checking C++11 support for "rvalue-references": works
-- Checking C++11 support for "sizeof_member"
-- Checking C++11 support for "sizeof_member": works
-- Checking C++11 support for "static_assert"
-- Checking C++11 support for "static_assert": works
-- Checking C++11 support for 

Re: [DynInst_API:] Dyninst-9.2 compile error on Intel Phi

[Jim Galarowicz]

Hi Bill,

Adding Type.h didn't change the behaviour unless it needs to be in a 
specific location in the include block?

This is the front-end build for MIC, so it is a x86_64 build.
I don't have this problem on my x864_64 laptop though.

Jim G


grep typeRef */*/*
dyninstAPI/src/BPatch_typePrivate.h:#define DYNINST_CLASS_NAME 
BPatch_typeRef
dyninstAPI/src/BPatch_typePrivate.h:class BPATCH_DLL_EXPORT 
BPatch_typeRef : public BPatch_type, public BPatch_fieldListInterface, 
public BPatch_rangedInterface {
dyninstAPI/src/BPatch_typePrivate.h:   BPatch_typeRef(int _ID, 
BPatch_type *_refType, const char *_name = NULL);
dyninstAPI/src/BPatch_typePrivate.h:   ~BPatch_typeRef() { 
refType->decrRefCount(); }
symtabAPI/doc/2-Abstractions.tex:node [class2] (typeRef) 
{typeRef}
symtabAPI/doc/2-Abstractions.tex:node [class2, below 
of=typeRef] (typePointer) {typePointer}

symtabAPI/doc/symtab-text.txt:typeRef *getRefType()
symtabAPI/doc/symtab-text.txt:If this Type object represents a 
Reference type, then return the object casting the Type object to 
typeRef otherwise return NULL.

symtabAPI/doc/symtab-text.txt:6.2.7.3 Class typeRef
symtabAPI/doc/symtab-text.txt:static typeRef *create(string , Type 
*ptr, int size,

symtabAPI/h/Type.h:class typeRef;
symtabAPI/h/Type.h:   typeRef *getRefType();
symtabAPI/h/Type.h:class SYMTAB_EXPORT typeRef : public derivedType {
symtabAPI/h/Type.h:   typeRef();
symtabAPI/h/Type.h:   typeRef(typeId_t ID, Type *refType, std::string name);
symtabAPI/h/Type.h:   typeRef(Type *refType, std::string name);
symtabAPI/h/Type.h:   static typeRef *create(std::string , Type 
*ptr, Symtab * obj = NULL);

symtabAPI/src/Type.C:max_size = MAX(sizeof(typeRef), max_size);
symtabAPI/src/Type.C:typeRef *Type::getRefType(){
symtabAPI/src/Type.C:return dynamic_cast(this);
symtabAPI/src/Type.C:if (getRefType()) return std::string("typeRef");
symtabAPI/src/Type.C:typeRef::typeRef(int ID, Type *refType, std::string 
name) :

symtabAPI/src/Type.C:typeRef::typeRef(Type *refType, std::string name) :
symtabAPI/src/Type.C:typeRef *typeRef::create(std::string , Type 
*ref, Symtab *obj)

symtabAPI/src/Type.C:   typeRef *typ = new typeRef(ref, name);
symtabAPI/src/Type.C:bool typeRef::operator==(const Type ) const {
symtabAPI/src/Type.C:  const typeRef  = dynamic_casttypeRef &>(otype);

symtabAPI/src/Type.C:bool typeRef::isCompatible(Type *otype) {
symtabAPI/src/Type.C:   typeRef *oReftype = dynamic_cast< typeRef *>(otype);
symtabAPI/src/Type.C:void typeRef::fixupUnknowns(Module *module)
symtabAPI/src/Type.C:typeRef::typeRef() {}
symtabAPI/src/Type.C:newt = new typeRef(ID_, NULL, name_);
symtabAPI/src/Type.C:void typeRef::serialize_specific(SerializerBase 
*sb) THROW_SPEC(SerializerError)

symtabAPI/src/Type.C:ifxml_start_element(sb, "typeRef");
symtabAPI/src/Type.C:ifxml_end_element(sb, "typeRef");
symtabAPI/src/Type.C:void typeRef::serialize_specific(SerializerBase *) 
THROW_SPEC(SerializerError)
symtabAPI/src/dwarfWalker.C: indirectType = new 
typeRef(type_id(), typePointedTo, curName());
symtabAPI/src/dwarfWalker.C: indirectType = 
tc()->addOrUpdateType((typeRef *) indirectType );
symtabAPI/src/parseStab.C:typeRef *newType = new typeRef(ID, 
ptrType, tName);

PBS maia97 50>

symtabAPI/src/Object-elf.C:#include "Type.h"
symtabAPI/src/Object.C:#include "Type.h"
symtabAPI/src/Type.C:#include "Type.h"
symtabAPI/src/dwarfWalker.C:#include "Type.h"
symtabAPI/src/parseDwarf.C:#include "Type.h"
dyninstAPI/src/BPatch_module.C:#include "symtabAPI/h/Type.h"// For 
BPatch_type related stuff

dyninstAPI/src/BPatch_snippet.C:#include "symtabAPI/h/Type.h"




On 07/06/2016 11:04 AM, Bill Williams wrote:

On 07/05/2016 09:11 PM, Jim Galarowicz wrote:

Hi Bill,

Thanks!   Adding the .c_str() got me quite a bit farther.
Now I'm getting this error.

Hrm. First question is whether adding "Type.h" to the include block 
fixes this--I'm surprised gnu doesn't have an issue with this 
instantiation.


--bw


Jim G

[ 26%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/emitElfStatic.C.o
[ 26%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/dwarfWalker.C.o
[ 26%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/emitElfStatic-x86.C.o
[ 27%] Building CXX object 
symtabAPI/CMakeFiles/symtabAPI.dir/src/relocationEntry-elf-x86.C.o

Linking CXX shared library libsymtabAPI.so
CMakeFiles/symtabAPI.dir/src/dwarfWalker.C.o: In function 
`Dyninst::SymtabAPI::DwarfWalker::parseTypeReferences()':
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia98/dyninst-9.2.0/symtabAPI/src/dwarfWalker.C:1270: 
undefined reference to `Dyninst::SymtabAPI::typeRef* 
Dyninst::SymtabAPI::typeCollection::addOrUpdateType(Dyninst::SymtabAPI::typeRef*)'

make[2]: *** [symtabAPI/libsymtabA

Re: [DynInst_API:] Dyninst-9.2 compile error on Intel Phi

[Jim Galarowicz]

make[2]: *** [symtabAPI/libsymtabAPI.so.9.2.0] Error 1
make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia98 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT

/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT
DYNINST FAILED TO BUILD - TERMINATING BUILD SCRIPT.  Please check for 
errors.


On 07/05/2016 03:16 PM, Bill Williams wrote:

On 07/05/2016 03:08 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

I'm trying to compile Dyninst for the Intel Phi and got the error below.

PBS maia97 28> icc -v
icc version 15.0.0 (gcc version 4.3.0 compatibility)

Is this due to the very old gcc that the Intel compiler is using 
under the hood for cxx11 checks, etc.?


Possibly. C++11 allows std::ifstream to be constructed from a string, 
but C++98 only allows a const char*. How old is that icc, anyway?


Easy enough to fix by adding a trailing .c_str() to the constructor 
arg, though.


--bw

Thanks,

Jim G


Continuing the dyninst build process.
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT
checking for 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/SOURCES/dyninst-9.2.0.patch

-- The C compiler identification is Intel 15.0.0.20140723
-- The CXX compiler identification is Intel 15.0.0.20140723
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc -- 
works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc 
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: 
x86_64-unknown-linux2.4
-- Found LibElf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libelf.so
-- Found LibDwarf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libdwarf.so
-- Found libiberty: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libiberty_pic.a
-- Using libiberty 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libiberty_pic.a

-- Found Thread_Db: /usr/lib64/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- Boost version: 1.53.0
-- Found the following Boost libraries:
--   thread
--   system
-- Boost includes: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/include
-- Boost library dirs: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib
-- Boost thread library: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_thread.so
-- Boost libraries: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_thread.so;//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_system.so

-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support for "__func__": works
-- Checking C++11 support for "auto"
-- Checking C++11 support for "auto": works
-- Checking C++11 support for "auto_ret_type"
-- Checking C++11 support for "auto_ret_type": works
-- Checking C++11 support for "class_override_final"
-- Checking C++11 support for "class_override_final": not supported
-- Checking C++11 support for "constexpr"
-- Checking C++11 support for "constexpr": works
-- Checking C++11 support for "cstdint"
-- Checking C++11 support for "cstdint": works
-- Checking C++11 support for "decltype"
-- Checking C++11 support for "decltype": works
-- Checking C++11 support for "initializer_list"
-- Checking C++11 support for "initializer_list": not supported
-- Checking C++11 support for "lambda"
-- Checking C++11 support for "lambda": works
-- Checking C++11 support for "long_long"
-- Checking C++11 support for "long_long": works
-- Checking C++11 support for "nullptr"
-- Checking C++11 support for "nullptr": works
-- Checking C++11 support for "regex"
-- Checking C++11 support for "regex": not supported
-- Checking C++11 support for "rvalue-references"
-- Checking C++11 support for "rvalue-references": works
-- Checking C++11 support for "sizeof_member"
-- Checking C++11 support for "sizeof_member": works
-- Checking C++11 support for "static_assert"
-- Checking C++11 support for "static_assert": works
-- Checking C++11 support for "variadic_templates"
-- C

[DynInst_API:] Dyninst-9.2 compile error on Intel Phi

[Jim Galarowicz]

Hi Bill, Dyninst team,

I'm trying to compile Dyninst for the Intel Phi and got the error below.

PBS maia97 28> icc -v
icc version 15.0.0 (gcc version 4.3.0 compatibility)

Is this due to the very old gcc that the Intel compiler is using under 
the hood for cxx11 checks, etc.?


Thanks,
Jim G


Continuing the dyninst build process.
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT
checking for 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/SOURCES/dyninst-9.2.0.patch

-- The C compiler identification is Intel 15.0.0.20140723
-- The CXX compiler identification is Intel 15.0.0.20140723
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc 
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc 
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: x86_64-unknown-linux2.4
-- Found LibElf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libelf.so
-- Found LibDwarf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libdwarf.so
-- Found libiberty: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libiberty_pic.a
-- Using libiberty 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libiberty_pic.a

-- Found Thread_Db: /usr/lib64/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- Boost version: 1.53.0
-- Found the following Boost libraries:
--   thread
--   system
-- Boost includes: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/include
-- Boost library dirs: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib
-- Boost thread library: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_thread.so
-- Boost libraries: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_thread.so;//nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib/libboost_system.so

-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support for "__func__": works
-- Checking C++11 support for "auto"
-- Checking C++11 support for "auto": works
-- Checking C++11 support for "auto_ret_type"
-- Checking C++11 support for "auto_ret_type": works
-- Checking C++11 support for "class_override_final"
-- Checking C++11 support for "class_override_final": not supported
-- Checking C++11 support for "constexpr"
-- Checking C++11 support for "constexpr": works
-- Checking C++11 support for "cstdint"
-- Checking C++11 support for "cstdint": works
-- Checking C++11 support for "decltype"
-- Checking C++11 support for "decltype": works
-- Checking C++11 support for "initializer_list"
-- Checking C++11 support for "initializer_list": not supported
-- Checking C++11 support for "lambda"
-- Checking C++11 support for "lambda": works
-- Checking C++11 support for "long_long"
-- Checking C++11 support for "long_long": works
-- Checking C++11 support for "nullptr"
-- Checking C++11 support for "nullptr": works
-- Checking C++11 support for "regex"
-- Checking C++11 support for "regex": not supported
-- Checking C++11 support for "rvalue-references"
-- Checking C++11 support for "rvalue-references": works
-- Checking C++11 support for "sizeof_member"
-- Checking C++11 support for "sizeof_member": works
-- Checking C++11 support for "static_assert"
-- Checking C++11 support for "static_assert": works
-- Checking C++11 support for "variadic_templates"
-- Checking C++11 support for "variadic_templates": works
-- C++11 support found, required flags are: -std=c++11
-- Enabling ThreadDB support
-- Set arch and platform based definitions
-- Options set
-- Set optimization flags
-- Building common...
-- Processing dependent target 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libiberty_pic.a...

-- Building dynElf...
-- Processing dependent target 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libelf.so...

-- Building dynDwarf...
-- Processing dependent target dynElf...
-- Found dependency location 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/elf

-- Processing dependent target common...
-- Found dependency location 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia97/dyninst-9.2.0/common
-- Processing dependent target 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libdwarf.so...
-- Processing dependent target 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.3/lib64/libelf.so...

-- Building symLite...

[DynInst_API:] Dyninst assert -- Re: Problem with running OpenSpeedShop - mpirun command?

[Jim Galarowicz]

Hi Mike,

I think the reason you aren't seeing that data is because Dyninst 
aborted while we were asking it to find the loops in your application.
You should see a by function list of the performance information as part 
of the default view generation from the osspcsamp command.
So, we probably have a Dyninst problem (which we don't see very often).  
I'm copying the Dyninst team on this one.


Bill, Dyninst team - do you have any ideas?   Have you seen this type of 
assert in the past?


Thanks,
Jim G

On 01/25/2016 12:28 PM, Mike Burklund wrote:

Jim,

Ok I used the full path to mpiexec.hydra and was able to get further.  
It complained about not having the env variable DYNINST_API_RT_LIB 
set.  I set this and ran again and was able to run.  I got this 
message (not sure if it is bad or not):


*ossutil: 
/opt/openss-2.2/openspeedshop-release-2.2/BUILD/hornberg/dyninst-8.2.1/dyninstAPI/src/binaryEdit.C:918: 
int_variable* BinaryEdit::createTrampGuard(): Assertion `rtlib.size()' 
failed.*


I'm just learning openspeedshop now, but when I look at the results 
with openss, it say:


(There are no objects specified for the basic Detail report.)

So, I guess I need to look into how to get sampling/timing results on 
the function level of my test application.


Thanks again,
Mike

On Mon, Jan 25, 2016 at 11:40 AM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi Mike,

You could also try setting OPENSS_MPI_IMPLEMENTATION=mpich2.  
This is only really supposed to matter for experiments= mpi, mpit

but it also is looked at for finding mpi driver commands.
There might be some special casing for that in the offline.py file.
You could also try the full path to the mpirun or mpirun.hydra
commands.

Jim G


On 01/25/2016 10:25 AM, Mike Burklund wrote:

Jim,

Thank you for your timely reply.

Regarding my mpirun command, it is installed with the fedora 23
mpich rpm and is a sym link to mpiexec.hyrdra in the same
directory.  Maybe the symbolic link is throwing things off.

I'll take a look at your sample module file to check my
installation and will let you know the results.

Thanks,
Mike

On Mon, Jan 25, 2016 at 11:04 AM, Jim Galarowicz
<j...@krellinst.org <mailto:j...@krellinst.org>> wrote:

Hi Mike,

I changed the Subject line to something more meaningful and
copied the oss-questions group, so that others might benefit
from what we discover.

This is an example module file for setting up the environment
to run OpenSpeedShop.
It looks like the build is correct (looking at the debug
output).   Seems like the problem is that we are not
recognizing the mpirun command as an mpi driver command.

I noticed from the output the OPENSS_RAWDATA_DIR is not being
set to a shared file system directory location.  We need that
to write the raw data out while the application is running,
then we read from that location at the end of execution to
create the database file that contains all the performance
data and your application program debug symbol information we
use to map the data to.

The other thing I can see from the debug startup output
(Thanks for that!) is that we don't seem to be recognizing
the mpirun command as the mpi driver.  The output says we are
running non-MPI.
So, is your mpirun command a script or an executable?   Is it
mpich based?
It must be an executable based on the output.   With no
symbols I might have to put a special case in our offline.py
file to force it to be known as a mpi driver.
I'm in Minnesota for a week and away from my office.  I have
a Fedora 23 system there and could try to reproduce, but that
won't be until next week.

So, the environment variables set in the module file are the
ones that are needed for successful runs of OpenSpeedShop.

I've attached a simple program to test a sequential test
program that will tell us if your installation is correct.

*$ cc -o mutatee -g -O0 mutatee.c**
**$ osspcsamp ./mutatee**
**$ module load ossoff222**
**$ osspcsamp ./mutatee*
[openss]: pcsamp experiment using the default sampling rate:
"100".
[openss]: Setting up offline raw data directory in
/opt/shared/offline-oss
[openss]: Running offline pcsamp experiment using the command:
"./mutatee"
work(900)=0

[openss]: Converting raw data from /opt/shared/offline-oss
into temp file X.0.openss

Processing raw data for mutatee ...
Processing processes and threads ...
Processing performance data ...
Processing symbols ...
Resolving symbols for

/home/j

Re: [DynInst_API:] Question about building Dyninst-9.1 release with Intel compilers

[Jim Galarowicz]

On 01/13/2016 09:49 AM, Josh Stone wrote:

On 01/13/2016 08:40 AM, Jim Galarowicz wrote:

[ 10%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/common/src/linuxKludges.C(1032):
error: no instance of constructor "std::basic_ifstream<_CharT,
_Traits>::basic_ifstream [with _CharT=char,
_Traits=std::char_traits]" matches the argument list
 argument types are: (std::basic_string<char,
std::char_traits, std::allocator>)
  std::ifstream maps_file(maps_filename.str());
  ^

The ifstream(string) constructor is a C++11 addition.
Is icc still using gcc's libstdc++?
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api


Hi Josh, Bill,

I added -std=c++11 to the compiler export:
   export cc="icc -std=c++11"
   export CXX="icpc -std=c++11"
   export CC="icc -std=c++11"
and it seems the Intel compilers have the c++11 support, or at least 
Dyninst says they do (see below).

But we get the same compile error.

Thanks,
Jim G


checking for 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/SOURCES/dyninst-9.1.0.patch

-- The C compiler identification is Intel 15.0.0.20140723
-- The CXX compiler identification is Intel 15.0.0.20140723
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc
-- Check for working C compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icc 
-- works

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc
-- Check for working CXX compiler: 
/nasa/intel/Compiler/2015.0.090/composer_xe_2015.0.090/bin/intel64/icpc 
-- works

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: x86_64-unknown-linux2.4
-- Found LibElf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib64/libelf.so
-- Found LibDwarf: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib64/libdwarf.so
-- Found libiberty: 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib64/libiberty_pic.a
-- Using libiberty 
/nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib64/libiberty_pic.a

-- Found Thread_Db: /usr/lib64/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:515 
] _boost_TEST_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0;1.57;1.57.0;1.58;1.58.0;1.59;1.59.0;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:517 
] Boost_USE_MULTITHREADED = ON
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:519 
] Boost_USE_STATIC_LIBS =
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:521 
] Boost_USE_STATIC_RUNTIME = OFF
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:523 
] Boost_ADDITIONAL_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0;1.57;1.57.0;1.58;1.58.0;1.59;1.59.0
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:525 
] Boost_NO_SYSTEM_PATHS = ON
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:577 
] Declared as CMake or Environmental Variables:
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:579 
]   BOOST_ROOT =
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:581 
]   BOOST_INCLUDEDIR =
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:583 
]   BOOST_LIBRARYDIR =
-- [ 
/nobackupp8/jgalarow/maia/cmake/share/cmake-3.2/Modules/FindBoost.cmake:585 
] _boost_TEST_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0;1.57;1.57.0;1.58;1.58.0;1.59;1.59.0;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ 
/nobackupp8/jgalarow/maia/cmake/sh

[DynInst_API:] Question about building Dyninst-9.1 release with Intel compilers

[Jim Galarowicz]

Hi Dyninst team,

I ran into some build problems with the Dyninst-9.1 release.
I'm on a platform that has an old gcc compiler that doesn't have support 
for C++11 auto (see just below) and there are no gcc alternatives.  I 
will check into seeing if the laboratory will upgrade gcc or offer a 
module alternative.


So, I tried using Intel compilers to build and got the compile error 
(see below - after gcc output).   Does Dyninst build with Intel compilers?


PBS maia111 5>*gcc -v*
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ 
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --program-suffix=-4.3 
--enable-linux-futex --without-system-libunwind --with-cpu=generic 
--build=x86_64-suse-linux

Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)


PBS maia111 6>*icc -v*
icc version 15.0.0 (gcc version 4.3.0 compatibility)
PBS maia111 7>


Thanks,
Jim G

*GCC OUTPUT:*

-- Boost includes: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/include
-- Boost library dirs: //nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib
-- Boost thread library: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib/libboost_thread.so
-- Boost libraries: 
//nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib/libboost_thread.so;//nobackupnfs2/jgalarow/maia/krellroot_v2.2.2/lib/libboost_system.so

-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Failed
-- Performing Test _HAS_CXX0X_FLAG
-- Performing Test _HAS_CXX0X_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support for "__func__": works
-- Checking C++11 support for "auto"
-- Checking C++11 support for "auto": not supported
-- Checking C++11 support for "auto_ret_type"
-- Checking C++11 support for "auto_ret_type": not supported
-- Checking C++11 support for "class_override_final"
-- Checking C++11 support for "class_override_final": not supported
-- Checking C++11 support for "constexpr"
-- Checking C++11 support for "constexpr": not supported
-- Checking C++11 support for "cstdint"
-- Checking C++11 support for "cstdint": works
-- Checking C++11 support for "decltype"
-- Checking C++11 support for "decltype": works
-- Checking C++11 support for "initializer_list"
-- Checking C++11 support for "initializer_list": not supported
-- Checking C++11 support for "lambda"
-- Checking C++11 support for "lambda": not supported
-- Checking C++11 support for "long_long"
-- Checking C++11 support for "long_long": works
-- Checking C++11 support for "nullptr"
-- Checking C++11 support for "nullptr": not supported
-- Checking C++11 support for "regex"
-- Checking C++11 support for "regex": not supported
-- Checking C++11 support for "rvalue-references"
-- Checking C++11 support for "rvalue-references": works
-- Checking C++11 support for "sizeof_member"
-- Checking C++11 support for "sizeof_member": not supported
-- Checking C++11 support for "static_assert"
-- Checking C++11 support for "static_assert": works
-- Checking C++11 support for "variadic_templates"
-- Checking C++11 support for "variadic_templates": works
CMake Error at cmake/packages.cmake:148 (message):
  No support for C++11 auto found.  Dyninst requires this compiler 
feature.

Call Stack (most recent call first):
  cmake/shared.cmake:82 (include)
  CMakeLists.txt:17 (include)


-- Configuring incomplete, errors occurred!
See also 
"/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/CMakeFiles/CMakeOutput.log".
See also 
"/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/CMakeFiles/CMakeError.log".

make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112 
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT




*USING INTEL COMPILERS:*


[  9%] Building CXX object common/CMakeFiles/common.dir/src/Buffer.C.o
[ 10%] Building CXX object common/CMakeFiles/common.dir/src/MachSyscall.C.o
[ 10%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/common/src/linuxKludges.C(1032): 
error: no instance of constructor "std::basic_ifstream<_CharT, 
_Traits>::basic_ifstream [with _CharT=char, 
_Traits=std::char_traits]" matches the argument list
argument types are: (std::basic_string)

 std::ifstream maps_file(maps_filename.str());
 ^

compilation 

[DynInst_API:] Abort on Xeon hosted dyninst running through Intel MIC application

[Jim Galarowicz]

Hi Bill, team,

I was trying to run OpenSpeedShop using Dyninst 9.0.3 (top of tree) on 
babbage (NERSC Intel MIC testbed) and got the core dump and traceback 
while OSS attempted to find the loops in the application.

I can send more details.  Maybe you can see something from the traceback.

As the subject indicates this was on the compute node Xeon (non-mic) 
host processor with dyninst running through Intel MIC application
There is one login node, and 45 compute nodes named “bc,” with two 
MIC cards and two Intel Xeon "host" processors within each compute 
node. Each Xeon processor (Sandy Bridge EP) contains 8 cores, capable 
of 2 hardware thread per core (hyperthreading is enabled) and 128 GB 
of memory per node. 



Thanks,
Jim G


*The files created:*

16 drwxr-xr-x 41 jgalaro jgalaro  8192 Dec  2 16:49 ../
 0 -rw---  1 jgalaro jgalaro48 Dec  2 16:49 micfile.9601
44 -rw---  1 jgalaro jgalaro 41984 Dec  2 16:52 
nbody.mic2-pcsamp-9.openss
132456 -rw---  1 jgalaro jgalaro 137863168 Dec  2 16:52 
core-bc0908-ossutil-11-49182-49182-25453-1449103939
 4 -rw---  1 jgalaro jgalaro   790 Dec  2 16:52 
my_job.pcsamp.err

32 drwx--  4 jgalaro jgalaro 16384 Dec  2 16:52 ./
 8 -rw---  1 jgalaro jgalaro  5295 Dec  2 16:52 
my_job.pcsamp.out



*Job output:*


bc0904 108% cat my_job.pcsamp.err
/usr/share/Modules/init/bash: line 2: unalias: sd_log: not found
/usr/share/Modules/init/bash: line 2: unalias: sc_log: not found
/global/u2/j/jgalaro/babbage/ossoff_stable/compute/bin/ossrun: line 134: 
/global/u2/j/jgalaro/babbage/krellroot_stable/bin/nm: cannot execute 
binary file
/global/u2/j/jgalaro/babbage/ossoff_stable/compute/bin/ossrun: line 134: 
/global/u2/j/jgalaro/babbage/krellroot_stable/bin/nm: cannot execute 
binary file

Processing raw data for nbody.mic2 ...
Processing processes and threads ...
Processing performance data ...
Processing symbols ...
Resolving symbols for /global/u2/j/jgalaro/nbody/nbody.mic2
Resolving symbols for 
/global/babbage/nsg/opt/intel/impi/5.0.1.035/mic/lib/release/libmpi.so.12.0

(There are no objects specified for the basic Detail report.)


*More job output:*

bc0904 109% cat my_job.pcsamp.out
/global/u2/j/jgalaro/babbage/ossoff_stable/compute/bin/ossrun
/global/u2/j/jgalaro/babbage/ossoff_stable/bin/ossmpi

[openss]: pcsamp experiment using the pcsamp experiment default sampling 
rate: "100".

[openss]: pcsamp experiment calling openss.
Iteration 1 of 50...
Iteration 2 of 50...
Iteration 3 of 50...
Iteration 4 of 50...
Iteration 5 of 50...
Iteration 6 of 50...
Iteration 7 of 50...
Iteration 8 of 50...
Iteration 9 of 50...
Iteration 10 of 50...
Iteration 11 of 50...
Iteration 12 of 50...
Iteration 13 of 50...
Iteration 14 of 50...
Iteration 15 of 50...
Iteration 16 of 50...
Iteration 17 of 50...
Iteration 18 of 50...
Iteration 19 of 50...
Iteration 20 of 50...
Iteration 21 of 50...
Iteration 22 of 50...
Iteration 23 of 50...
Iteration 24 of 50...
Iteration 25 of 50...
Iteration 26 of 50...
Iteration 27 of 50...
Iteration 28 of 50...
Iteration 29 of 50...
Iteration 30 of 50...
Iteration 31 of 50...
Iteration 32 of 50...
Iteration 33 of 50...
Iteration 34 of 50...
Iteration 35 of 50...
Iteration 36 of 50...
Iteration 37 of 50...
Iteration 38 of 50...
Iteration 39 of 50...
Iteration 40 of 50...
Iteration 41 of 50...
Iteration 42 of 50...
Iteration 43 of 50...
Iteration 44 of 50...
Iteration 45 of 50...
Iteration 46 of 50...
Iteration 47 of 50...
Iteration 48 of 50...
Iteration 49 of 50...
Iteration 50 of 50...
[openss]: Setting up offline raw data directory in 
/global/u2/j/jgalaro/babbage/shared/offline-oss

[openss]: Running offline pcsamp experiment using the command:
"/usr/common/usg/bin/mpirun.mic -genvall -n 2 -hostfile micfile.9601 
-ppn 1 -env OPENSS_MPI_IMPLEMENTATION mpich2 -env OPENSS_PLUGIN_PATH 
/global/u2/j/jgalaro/babbage/ossoff_v2.1u5/compute_intel/lib64/openspeedshop 
-env OPENSS_RAWDATA_DIR /global/u2/j/jgalaro/babbage/shared/offline-oss 
-env PATH 

Re: [DynInst_API:] Dyninst building with Intel compilers?

[Jim Galarowicz]

Hi Bill,

Would I have to set PLATFORM?   When I echo "PLATFORM=$PLATFORM" before the
cmake command, it is null/empty.

Thanks
Jim G

running cmake for Intel mic
platform=
PLATFORM=


On Wed, Nov 25, 2015 at 1:37 PM, Jim Galarowicz <j...@krellinst.org> wrote:

> Hi Bill,
>
> I added the -std=c++11 option in this fashion, but no difference in the
> results.
>
> -DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2 "
> -DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2"
>
> The cmake command:
>
>  elif [ "$KRELL_ROOT_TARGET_ARCH" == "mic" ]; then
>
>export cc=icc
>export CXX=icpc
>export CC=icc
>echo "running cmake for Intel mic"
>
>cmake . -DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
> -DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR
> -DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dyninst
> -DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
> -DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2 "
> -DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2"
> -DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME -DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC
> -DLIBELF_LIBRARIES=$LIBELF_LIBNAME -DLIBELF_INCLUDE_DIR=$LIBELFINC
> -DPATH_BOOST=$DYNINST_BOOST_ROOT -DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME
> -DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME
>
>  else
>
> I'm getting the echo, so I know we are getting into this cmake command.
>
> Jim G
>
>
> On 11/25/2015 08:56 AM, Bill Williams wrote:
>
>> On 11/24/2015 02:50 PM, Jim Galarowicz wrote:
>>
>>> Hi Bill, Rashawn, all,
>>>
>>> It looks like the source changes for Intel builds are already in my
>>> version.
>>>
>>> Bill - I've attached the log file: CMakeFiles/CMakeOutput.log
>>> I had to cat it mouse it up and paste into a file on my laptop. That is
>>> attached.
>>>
>>>
>>> Thanks,
>>> Jim G
>>>
>>> So it's trying -std=c++11, which should be sane I think. The error log
>> should show what went wrong with the auto test; that's not in the output
>> log unfortunately.
>>
>>
>>> On 11/24/2015 11:27 AM, Jim Galarowicz wrote:
>>>
>>>> Hi Rashawn, Bill,
>>>>
>>>> Thanks for this information!  I will add the suggestions and see if I
>>>> can get farther.
>>>>
>>>> Yes, I do want to collaborate with the members of your team. I'm on
>>>> babbage at NERSC and I'm having trouble building libdwarf for the
>>>> target/compute nodes.  I know I did build libdwarf a couple of months ago,
>>>> but now the configure is erroring me out because it doesn't like the libelf
>>>> I built. It seems like I don't have the right configure options and is
>>>> trying to do a native build time configure check.
>>>>
>>>> Thanks,
>>>> Jim G
>>>>
>>>> On 11/24/2015 09:28 AM, Knapp, Rashawn L wrote:
>>>>
>>>>> Bill and Jim,
>>>>>
>>>>> The two files modified to enable Intel compilation were
>>>>> cmake/optimization.cmake and cmake/warnings.cmake.  The changes are now in
>>>>> the 9.0.3 source from the git repo, and should contain the following:
>>>>>
>>>>> optimization.cmake:
>>>>> if (CMAKE_COMPILER_IS_GNUCXX
>>>>>  OR  "${CMAKE_C_COMPILER_ID}" MATCHES Clang
>>>>>  OR "${CMAKE_C_COMPILER_ID}" MATCHES GNU
>>>>>  OR "${CMAKE_C_COMPILER_ID}" MATCHES Intel)
>>>>>  ...
>>>>>
>>>>> warnings.cmake:
>>>>> if (CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_C_COMPILER_ID}" MATCHES INTEL)
>>>>> ...
>>>>>
>>>>> We have built and tested 9.0.3 on KNL using the new Intel 16.*
>>>>> compilers.  We have a recent build of OSS 2.2 using Dyninst 9.0.3 on
>>>>> HSW-EP, but we have not ported this yet to KNL.  Jim, I can put you in
>>>>> touch with my team members who have been working on this. Let me know if
>>>>> you would like to meet.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rashawn Knapp
>>>>> Software Development Engineer, Intel Corporation
>>>>> Systems Engineering, Architecture & Runtimes
>>>>> Pole: JF2-1-N8 | MS: JF2-1-70-84| O: 503-264-4221
>>>>>
>>>>>
>>>>>
>>

Re: [DynInst_API:] Dyninst building with Intel compilers?

[Jim Galarowicz]

Hi Rashawn, Bill,

Thanks for that information!

I guess, that was not the immediate issue.   I'm sure I must be doing 
something wrong, but don't know what yet.


I added debug to the cmake/CheckCXX11Features.cmake file:

set(_SRCFILE_FAIL_COMPILE "${_SRCFILE_BASE}_fail_compile.cpp")

message(STATUS "Checking C++11 support, 
CMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}")
message(STATUS "Checking C++11 support, 
CMAKE_C_COMPILER=${CMAKE_C_COMPILER}")
message(STATUS "Checking C++11 support, 
CROSS_COMPILING=${CROSS_COMPILING}")
message(STATUS "Checking C++11 support, 
CXX11_COMPILER_FLAGS=${CXX11_COMPILER_FLAGS}")

message(STATUS "Checking C++11 support, _SRCFILE=${_SRCFILE}")

if (CROSS_COMPILING)

to see if I'm getting the correct compiler.   The results below indicate 
that I am.  The CXX11_COMPILER_FLAGS seem reasonable.

The checks apparently just fail for some reason.

Jim G

- Boost libraries: 
/usr/lib64/libboost_thread-mt.so;/usr/lib64/libboost_system-mt.so

-- Performing Test _HAS_CXX11_FLAG
-- Performing Test _HAS_CXX11_FLAG - Success
-- Checking C++11 support for "__func__"
-- Checking C++11 support, 
CMAKE_CXX_COMPILER=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icpc
-- Checking C++11 support, 
CMAKE_C_COMPILER=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc

-- Checking C++11 support, CROSS_COMPILING=
-- Checking C++11 support, CXX11_COMPILER_FLAGS=-std=c++11
-- Checking C++11 support, 
_SRCFILE=/global/homes/j/jgalaro/babbage/OpenSpeedShop_ROOT/BUILD/bint01/dyninst-9.0.3/cmake/CheckCXX11Features/cxx11-test-__func__.cpp

-- Checking C++11 support for "__func__": not supported
-- Checking C++11 support for "auto"
-- Checking C++11 support, 
CMAKE_CXX_COMPILER=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icpc
-- Checking C++11 support, 
CMAKE_C_COMPILER=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc

-- Checking C++11 support, CROSS_COMPILING=
-- Checking C++11 support, CXX11_COMPILER_FLAGS=-std=c++11
-- Checking C++11 support, 
_SRCFILE=/global/homes/j/jgalaro/babbage/OpenSpeedShop_ROOT/BUILD/bint01/dyninst-9.0.3/cmake/CheckCXX11Features/cxx11-test-auto.cpp

-- Checking C++11 support for "auto": not supported
-- Checking C++11 support for "auto_ret_type"

On 11/25/2015 03:09 PM, Knapp, Rashawn L wrote:


Jim,

On our HSW-EP and  on our KNL install of Dyninst we set the $PLATFORM 
to x86_64-unknown-linux2.6.


Regards,

-Rashawn

*From:*Jim Galarowicz [mailto:j...@krellinst.org]
*Sent:* Wednesday, November 25, 2015 3:00 PM
*To:* Bill Williams <b...@cs.wisc.edu>; Knapp, Rashawn L 
<rashawn.l.kn...@intel.com>; dyninst-api@cs.wisc.edu
*Cc:* Suman, Preeti <preeti.su...@intel.com>; Mineeva, Tatyana A 
<tatyana.a.mine...@intel.com>

*Subject:* Re: [DynInst_API:] Dyninst building with Intel compilers?

Hi Bill,

Would I have to set PLATFORM?   When I echo "PLATFORM=$PLATFORM" 
before the cmake command, it is null/empty.


Thanks

Jim G


running cmake for Intel mic
platform=
PLATFORM=

On Wed, Nov 25, 2015 at 1:37 PM, Jim Galarowicz <j...@krellinst.org 
<mailto:j...@krellinst.org>> wrote:


Hi Bill,

I added the -std=c++11 option in this fashion, but no difference
in the results.

-DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2 "
-DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2"

The cmake command:

 elif [ "$KRELL_ROOT_TARGET_ARCH" == "mic" ]; then

   export cc=icc
   export CXX=icpc
   export CC=icc
   echo "running cmake for Intel mic"

   cmake .
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dyninst
-DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2
" -DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2"
-DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC
-DLIBELF_LIBRARIES=$LIBELF_LIBNAME -DLIBELF_INCLUDE_DIR=$LIBELFINC
-DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME
-DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME

 else

I'm getting the echo, so I know we are getting into this cmake
command.

Jim G


On 11/25/2015 08:56 AM, Bill Williams wrote:

On 11/24/2015 02:50 PM, Jim Galarowicz wrote:

Hi Bill, Rashawn, all,

It looks like the source changes for Intel builds are
already in my version.

Bill - I've attached the log file: CMakeFiles/CMakeOutput.log
I had to cat it mouse it up and paste into a file on my
laptop. That

Re: [DynInst_API:] Dyninst building with Intel compilers?

[Jim Galarowicz]

Hi Bill,

I added the -std=c++11 option in this fashion, but no difference in the 
results.


-DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2 "
-DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2"

The cmake command:

 elif [ "$KRELL_ROOT_TARGET_ARCH" == "mic" ]; then

   export cc=icc
   export CXX=icpc
   export CC=icc
   echo "running cmake for Intel mic"

   cmake . 
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX 
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR 
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dyninst 
-DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX 
-DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-std=c++11 -mmic -g -O2 " 
-DCMAKE_C_FLAGS="-std=c++11 -mmic -g -O2" 
-DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME 
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC -DLIBELF_LIBRARIES=$LIBELF_LIBNAME 
-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT 
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME -DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME


 else

I'm getting the echo, so I know we are getting into this cmake command.

Jim G


On 11/25/2015 08:56 AM, Bill Williams wrote:

On 11/24/2015 02:50 PM, Jim Galarowicz wrote:

Hi Bill, Rashawn, all,

It looks like the source changes for Intel builds are already in my 
version.


Bill - I've attached the log file: CMakeFiles/CMakeOutput.log
I had to cat it mouse it up and paste into a file on my laptop. That 
is attached.



Thanks,
Jim G

So it's trying -std=c++11, which should be sane I think. The error log 
should show what went wrong with the auto test; that's not in the 
output log unfortunately.




On 11/24/2015 11:27 AM, Jim Galarowicz wrote:

Hi Rashawn, Bill,

Thanks for this information!  I will add the suggestions and see if 
I can get farther.


Yes, I do want to collaborate with the members of your team. I'm on 
babbage at NERSC and I'm having trouble building libdwarf for the 
target/compute nodes.  I know I did build libdwarf a couple of 
months ago, but now the configure is erroring me out because it 
doesn't like the libelf I built. It seems like I don't have the 
right configure options and is trying to do a native build time 
configure check.


Thanks,
Jim G

On 11/24/2015 09:28 AM, Knapp, Rashawn L wrote:

Bill and Jim,

The two files modified to enable Intel compilation were 
cmake/optimization.cmake and cmake/warnings.cmake.  The changes are 
now in the 9.0.3 source from the git repo, and should contain the 
following:


optimization.cmake:
if (CMAKE_COMPILER_IS_GNUCXX
 OR  "${CMAKE_C_COMPILER_ID}" MATCHES Clang
 OR "${CMAKE_C_COMPILER_ID}" MATCHES GNU
 OR "${CMAKE_C_COMPILER_ID}" MATCHES Intel)
 ...

warnings.cmake:
if (CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_C_COMPILER_ID}" MATCHES 
INTEL)

...

We have built and tested 9.0.3 on KNL using the new Intel 16.* 
compilers.  We have a recent build of OSS 2.2 using Dyninst 9.0.3 
on HSW-EP, but we have not ported this yet to KNL.  Jim, I can put 
you in touch with my team members who have been working on this. 
Let me know if you would like to meet.


Regards,

Rashawn Knapp
Software Development Engineer, Intel Corporation
Systems Engineering, Architecture & Runtimes
Pole: JF2-1-N8 | MS: JF2-1-70-84| O: 503-264-4221



-Original Message-
From: Dyninst-api [mailto:dyninst-api-boun...@cs.wisc.edu] On 
Behalf Of Bill Williams

Sent: Tuesday, November 24, 2015 9:13 AM
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] Dyninst building with Intel compilers?

On 11/23/2015 07:01 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

I forgot to include how I'm calling cmake.  Maybe this isn't the best
way to do it?

export cc=icc
export CXX=icpc
export CC=icc

cmake .
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dynin 


st -DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-mmic -g -O2 "
-DCMAKE_C_FLAGS="-mmic -g -O2" -DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC 
-DLIBELF_LIBRARIES=$LIBELF_LIBNAME

-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME
-DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME

I know that Dyninst 9 builds with icc, thanks to Rashawn Knapp, and 
if memory serves it shares flags with gcc for the most part. I 
don't think that overriding the build type and C/CXX flags should 
break anything but you can always try adding -mmic (if it's even 
needed for Dyninst; it may only be needed for the runtime library 
or not at all) to the optimization.cmake defines and using a 
"normal" build type. The other option is forcing the correct C++11 
flag; the checks there could spuriously pass if both C+

Re: [DynInst_API:] Dyninst building with Intel compilers?

[Jim Galarowicz]

Hi Bill, Rashawn, all,

It looks like the source changes for Intel builds are already in my 
version.


Bill - I've attached the log file: CMakeFiles/CMakeOutput.log
I had to cat it mouse it up and paste into a file on my laptop. That is 
attached.



Thanks,
Jim G


On 11/24/2015 11:27 AM, Jim Galarowicz wrote:

Hi Rashawn, Bill,

Thanks for this information!  I will add the suggestions and see if I 
can get farther.


Yes, I do want to collaborate with the members of your team.  I'm on 
babbage at NERSC and I'm having trouble building libdwarf for the 
target/compute nodes.  I know I did build libdwarf a couple of months 
ago, but now the configure is erroring me out because it doesn't like 
the libelf I built.   It seems like I don't have the right configure 
options and is trying to do a native build time configure check.


Thanks,
Jim G

On 11/24/2015 09:28 AM, Knapp, Rashawn L wrote:

Bill and Jim,

The two files modified to enable Intel compilation were 
cmake/optimization.cmake and cmake/warnings.cmake.  The changes are 
now in the 9.0.3 source from the git repo, and should contain the 
following:


optimization.cmake:
if (CMAKE_COMPILER_IS_GNUCXX
 OR  "${CMAKE_C_COMPILER_ID}" MATCHES Clang
 OR "${CMAKE_C_COMPILER_ID}" MATCHES GNU
 OR "${CMAKE_C_COMPILER_ID}" MATCHES Intel)
 ...

warnings.cmake:
if (CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_C_COMPILER_ID}" MATCHES INTEL)
...

We have built and tested 9.0.3 on KNL using the new Intel 16.* 
compilers.  We have a recent build of OSS 2.2 using Dyninst 9.0.3 on 
HSW-EP, but we have not ported this yet to KNL.  Jim, I can put you 
in touch with my team members who have been working on this. Let me 
know if you would like to meet.


Regards,

Rashawn Knapp
Software Development Engineer, Intel Corporation
Systems Engineering, Architecture & Runtimes
Pole: JF2-1-N8 | MS: JF2-1-70-84| O: 503-264-4221



-Original Message-
From: Dyninst-api [mailto:dyninst-api-boun...@cs.wisc.edu] On Behalf 
Of Bill Williams

Sent: Tuesday, November 24, 2015 9:13 AM
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] Dyninst building with Intel compilers?

On 11/23/2015 07:01 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

I forgot to include how I'm calling cmake.  Maybe this isn't the best
way to do it?

export cc=icc
export CXX=icpc
export CC=icc

cmake .
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dynin
st -DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-mmic -g -O2 "
-DCMAKE_C_FLAGS="-mmic -g -O2" -DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC -DLIBELF_LIBRARIES=$LIBELF_LIBNAME
-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME
-DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME

I know that Dyninst 9 builds with icc, thanks to Rashawn Knapp, and 
if memory serves it shares flags with gcc for the most part. I don't 
think that overriding the build type and C/CXX flags should break 
anything but you can always try adding -mmic (if it's even needed for 
Dyninst; it may only be needed for the runtime library or not at all) 
to the optimization.cmake defines and using a "normal" build type. 
The other option is forcing the correct C++11 flag; the checks there 
could spuriously pass if both C++0x and C++11 flags are accepted 
without error, but only one of them actually enables the C++11 features.


The cmake logs should show which C++11 flag it's trying and what the 
result of compiling the "auto" test file is; that would be informative.



Thanks,
Jim G


On 11/23/2015 04:13 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

Does Dyninst build with Intel compilers?   I'm trying to build on an
Intel MIC platform but I can't get by the C++11 support checks.

Thanks for any advice.   This is the top of tree source code.

Thanks,
Jim G


~/babbage/OpenSpeedShop_ROOT/BUILD/bint01
~/babbage/OpenSpeedShop_ROOT
~/babbage/OpenSpeedShop_ROOT/BUILD/bint01/dyninst-9.0.3
~/babbage/OpenSpeedShop_ROOT/BUILD/bint01
~/babbage/OpenSpeedShop_ROOT checking for
/global/homes/j/jgalaro/babbage/OpenSpeedShop_ROOT/SOURCES/dyninst-9.
0.3.patch
-- The C compiler identification is Intel 16.0.0.20150815
-- The CXX compiler identification is Intel 16.0.0.20150815
-- Check for working C compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc
-- Check for working C compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc --
works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icpc
-- Check for working CXX compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/in

Re: [DynInst_API:] Dyninst building with Intel compilers?

[Jim Galarowicz]

Hi Rashawn, Bill,

Thanks for this information!  I will add the suggestions and see if I 
can get farther.


Yes, I do want to collaborate with the members of your team.  I'm on 
babbage at NERSC and I'm having trouble building libdwarf for the 
target/compute nodes.  I know I did build libdwarf a couple of months 
ago, but now the configure is erroring me out because it doesn't like 
the libelf I built.   It seems like I don't have the right configure 
options and is trying to do a native build time configure check.


Thanks,
Jim G

On 11/24/2015 09:28 AM, Knapp, Rashawn L wrote:

Bill and Jim,

The two files modified to enable Intel compilation were 
cmake/optimization.cmake and cmake/warnings.cmake.  The changes are now in the 
9.0.3 source from the git repo, and should contain the following:

optimization.cmake:
if (CMAKE_COMPILER_IS_GNUCXX
 OR  "${CMAKE_C_COMPILER_ID}" MATCHES Clang
 OR "${CMAKE_C_COMPILER_ID}" MATCHES GNU
 OR "${CMAKE_C_COMPILER_ID}" MATCHES Intel)
 ...

warnings.cmake:
if (CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_C_COMPILER_ID}" MATCHES INTEL)
...

We have built and tested 9.0.3 on KNL using the new Intel 16.* compilers.  We 
have a recent build of OSS 2.2 using Dyninst 9.0.3 on HSW-EP, but we have not 
ported this yet to KNL.  Jim, I can put you in touch with my team members who 
have been working on this. Let me know if you would like to meet.

Regards,

Rashawn Knapp
Software Development Engineer, Intel Corporation
Systems Engineering, Architecture & Runtimes
Pole: JF2-1-N8 | MS: JF2-1-70-84| O: 503-264-4221



-Original Message-
From: Dyninst-api [mailto:dyninst-api-boun...@cs.wisc.edu] On Behalf Of Bill 
Williams
Sent: Tuesday, November 24, 2015 9:13 AM
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] Dyninst building with Intel compilers?

On 11/23/2015 07:01 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

I forgot to include how I'm calling cmake.  Maybe this isn't the best
way to do it?

export cc=icc
export CXX=icpc
export CC=icc

cmake .
-DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/$LIBDIR
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX/include/dynin
st -DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT/$KRELL_ROOT_PREFIX
-DCMAKE_BUILD_TYPE=None -DCMAKE_CXX_FLAGS="-mmic -g -O2 "
-DCMAKE_C_FLAGS="-mmic -g -O2" -DLIBDWARF_LIBRARIES=$LIBDWARF_LIBNAME
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC -DLIBELF_LIBRARIES=$LIBELF_LIBNAME
-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME
-DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME


I know that Dyninst 9 builds with icc, thanks to Rashawn Knapp, and if memory serves it 
shares flags with gcc for the most part. I don't think that overriding the build type and 
C/CXX flags should break anything but you can always try adding -mmic (if it's even 
needed for Dyninst; it may only be needed for the runtime library or not at all) to the 
optimization.cmake defines and using a "normal" build type. The other option is 
forcing the correct C++11 flag; the checks there could spuriously pass if both C++0x and 
C++11 flags are accepted without error, but only one of them actually enables the C++11 
features.

The cmake logs should show which C++11 flag it's trying and what the result of compiling 
the "auto" test file is; that would be informative.


Thanks,
Jim G


On 11/23/2015 04:13 PM, Jim Galarowicz wrote:

Hi Bill, Dyninst team,

Does Dyninst build with Intel compilers?   I'm trying to build on an
Intel MIC platform but I can't get by the C++11 support checks.

Thanks for any advice.   This is the top of tree source code.

Thanks,
Jim G


~/babbage/OpenSpeedShop_ROOT/BUILD/bint01
~/babbage/OpenSpeedShop_ROOT
~/babbage/OpenSpeedShop_ROOT/BUILD/bint01/dyninst-9.0.3
~/babbage/OpenSpeedShop_ROOT/BUILD/bint01
~/babbage/OpenSpeedShop_ROOT checking for
/global/homes/j/jgalaro/babbage/OpenSpeedShop_ROOT/SOURCES/dyninst-9.
0.3.patch
-- The C compiler identification is Intel 16.0.0.20150815
-- The CXX compiler identification is Intel 16.0.0.20150815
-- Check for working C compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc
-- Check for working C compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icc --
works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icpc
-- Check for working CXX compiler:
/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/icpc --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform:
x86_64-unknown-linux2.4
-- Found LibElf:
/global/u2/j/jgalaro/babbage/krellroot_stable/compute/lib64/libelf.so
-- Could NOT find LibDwarf (missing: 

Re: [DynInst_API:] Not getting sources lines question: getSourceLines API

[Jim Galarowicz]

:vector<BPatch_basicBlock*>::iterator bbe;

   // filesAndlines: Return value file names and line 
numbers from getSourceLines

   std::vector filesAndlines ;

   // Loop through the loops basic blocks, get the 
starting address of the block
   // Then use that address to get the filename and 
line number for that address
   // We are looking for the minimum line number for 
the blocks in the loop to use

   // as the loop head basic block.

   head = entries[0]; // give an initial value to the 
loop head
   for (bbe = entries.begin(); bbe != entries.end(); 
++bbe) {


 unsigned long module_base = 
(uint64_t)module->getBaseAddr();
 unsigned long bbstartAddr = 
(*bbe)->getStartAddress() - module_base;


 bool linesFound = module->getSourceLines( 
bbstartAddr, filesAndlines);


 if (linesFound) {
std::vector::iterator lf_dx;
for (lf_dx = filesAndlines.begin(); lf_dx != 
filesAndlines.end(); ++lf_dx) {
std::cerr << "fileName=" << 
(*lf_dx).fileName() << " lineNumber=" << (*lf_dx).lineNumber() << 
std::endl;

}

  } // linesFound

   } // entries
#else
   BPatch_basicBlock* head = loop->getLoopHead();
#endif

if (head == NULL)
{
continue;
}

// Use the loop head basic block to create the 
necessary loop information to return
LoopInfo info(Address(head->getStartAddress()) - 
module_base);


BPatch_Vector<BPatch_basicBlock*> blocks;
loop->getLoopBasicBlocks(blocks);

for (unsigned int i = 0; i < blocks.size(); ++i)
{
BPatch_basicBlock* block = blocks[i];

if (block != NULL)
{
info.dm_ranges.push_back(
AddressRange(
Address(block->getStartAddress()) - 
module_base,
Address(block->getEndAddress()) - 
module_base

        )
);
}
}

retval.push_back(info);

} // l
} // f
} // m

return retval;
}

On 09/11/2015 02:42 PM, Jim Galarowicz wrote:



Hi all,

I'm trying to use the new loop API to find the head basic block for 
loops in the applications we are doing performance analysis on.

The old api had a function for that:

BPatch_basicBlock* head = loop->getLoopHead();

but now, we need to figure it out on our own.

I must be doing something wrong because I never get any source lines 
returned from the


bool linesFound = module->getSourceLines( bbstartAddr, filesAndlines);

call below.   The new code is bracketed by the #if 
DyninstAPI_VERSION_MAJOR >= 9 line below.


Does anyone see anything obvious that I'm doing wrong?

I checked for the presence of the dwarf information via dwarfdump and 
there appears to be statement information present.


This is the function from DyninstSymbols.cxx from our OpenSpeedShop 
code, that I'm working on to get loop info:


/** Get the loops containing the specified address. */
std::vector getLoopsAt(const Address& address,
BPatch_image& image)
{
std::vector retval;

// Iterate over each module within the specified image

BPatch_Vector<BPatch_module*>* modules = image.getModules();

if (modules == NULL)
{
return retval;
}

for (unsigned int m = 0; m < modules->size(); ++m)
{
BPatch_module* module = (*modules)[m];

if (module == NULL)
{
continue;
}

Address module_base = (uint64_t)module->getBaseAddr();

// Find the function(s) containing the specified address

BPatch_Vector<BPatch_function*> functions;
module->findFunctionByAddress(
(void*)((module_base + address).getValue()),
functions, false, false
);

for (unsigned int f = 0; f < functions.size(); ++f)
{
BPatch_function* function = functions[f];

if (function == NULL)
{
continue;
}

// Find the loops containing the specified address

BPatch_flowGraph* cfg = function->getCFG();

if (cfg == NULL)
{
continue;
}

Re: [DynInst_API:] Dyninst 8.2.1 fails to build on Titan

[Jim Galarowicz]

   # else
   296#  define INT64_C(c)c ## LL
   297# endif
   298
   299/* Unsigned.  */
   300# define UINT8_C(c)c
   301# define UINT16_C(c)c
   302# define UINT32_C(c)c ## U
   303# if __WORDSIZE == 64
   304#  define UINT64_C(c)c ## UL
   305# else
   306#  define UINT64_C(c)c ## ULL
   307# endif
   308
   309/* Maximal type.  */
   310# if __WORDSIZE == 64
   311#  define INTMAX_C(c)c ## L
   312#  define UINTMAX_C(c)c ## UL
   313# else
   314#  define INTMAX_C(c)c ## LL
   315#  define UINTMAX_C(c)c ## ULL
   316# endif
   317
   318#endif/* C++ && constant macros */
   319
   320#endif /* stdint.h */
On 12/03/2014 02:04 PM, Matthew LeGendre wrote:




On Wed, 3 Dec 2014, Jim Galarowicz wrote:

Hi Dyninst team,

Does anyone in the Dyninst group have access to Titan at ORNL?
If so, I'm wondering if someone could try building Dyninst there.   I
believe I'm building Dyninst in the same way we do on all other 
Cray's where

we don't see this problem.
So, it would be good to have a sanity check.
I reported this with Dyninst 8.2.0 and the consensus was that the 
include

files were somehow not getting process in the proper order.
Something might be wrong with the include layout on Titan.

Thanks,
Jim G

 ^
Linking CXX shared library libpatchAPI.so
[ 39%] Built target patchAPI
Scanning dependencies of target dyninstAPI
[ 39%] Building CXX object
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/BPatch.C.o
In file included 
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/

src/headers.h:53:0,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/
src/Timer.h:43,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/
src/stats.h:38,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/dyninst
API/src/BPatch.C:43:
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/fraction.h: In constructor 'fraction::fraction(int64_t)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/Types.h:140:28: error: 'INT64_C' was not declared in this scope
 #define I64_C(x)  INT64_C(x)
^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/fraction.h:59:50: note: in expansion of macro 'I64_C'
   explicit fraction(int64_t n) : numer(n), denom(I64_C(1))  {
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/arch-x86.h: In function 'bool NS_x86::is_disp32(long int)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/Types.h:158:18: error: 'INT32_MAX' was not declared in this scope
 #define I32_MAX  INT32_MAX
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/arch-x86.h:907:19: note: in expansion of macro 'I32_MAX'
   return (disp <= I32_MAX && disp >= I32_MIN);
   ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/Types.h:159:18: error: 'INT32_MIN' was not declared in this scope
 #define I32_MIN  INT32_MIN
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/arch-x86.h:907:38: note: in expansion of macro 'I32_MIN'
   return (disp <= I32_MAX && disp >= I32_MIN);
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/arch-x86.h: In function 'bool NS_x86::is_addr32(Dyninst::Address)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/Types.h:160:18: error: 'UINT32_MAX' was not declared in this scope
 #define UI32_MAX UINT32_MAX
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/ 


src/arch-x86.h:913:20: note: in expansion of macro 'UI32_MAX'
 return (addr < UI32_MAX);
^
In file included 
from/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/system/

system_error.hpp:14:0,
from/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/
exceptions.hpp:22,
from/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/
pthread/thread_data.hpp:10,
from/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/
pthread/condition_variable.hpp:12,
from/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/
condition_variable.hpp:16,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/common/
src/dthread.h:38,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/dyninst
API/src/pcEventHandler.h:39,
from/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext5/dyninst-8.2.1/dyninst
API/src/dynProcess.h:45,
from/ccs/home/jgala

[DynInst_API:] Dyninst on aarch64 ARM system doesn't build (for me)

[Jim Galarowicz]

Hi all,

I downloaded the git repository version of Dyninst a few minutes ago and 
tried to build on an ARM based system (64-bit aarch64).
It looks like Dyninst is looking for a file named: 
src/RTthread-aarch64-asm.S but can't find it.


Can anyone help with this issue?Maybe my cmake line is not correct?

Thanks,
Jim G

+ pushd dyninst-9.0.0
~/OpenSpeedShop_ROOT/BUILD/node045/dyninst-9.0.0 
~/OpenSpeedShop_ROOT/BUILD/node045 ~/OpenSpeedShop_ROOT

+ '[' -f ../dyninst-9.0.0.patch ']'
++ pwd
+ export 
DYNINST_ROOT=/home/jgalaro/OpenSpeedShop_ROOT/BUILD/node045/dyninst-9.0.0/dyninst-9.0.0
+ 
DYNINST_ROOT=/home/jgalaro/OpenSpeedShop_ROOT/BUILD/node045/dyninst-9.0.0/dyninst-9.0.0

+ '[' '' == bgp ']'
+ '[' '' == bgq ']'
+ cmake . -DCMAKE_INSTALL_PREFIX=//home/jgalaro/dyninst900 
-DINSTALL_LIB_DIR=//home/jgalaro/dyninst900/lib 
-DINSTALL_INCLUDE_DIR=//home/jgalaro/dyninst900/include/dyninst 
-DCMAKE_PREFIX_PATH=//home/jgalaro/dyninst900 
-DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DLIBDWARF_LIBRARIES=/home/jgalaro/rootu7/lib/libdwarf.so 
-DLIBDWARF_INCLUDE_DIR=/home/jgalaro/rootu7/include 
-DLIBELF_LIBRARIES=/home/jgalaro/rootu7/lib/libelf.so 
-DLIBELF_INCLUDE_DIR=/home/jgalaro/rootu7/include 
-DPATH_BOOST=/home/jgalaro/rootu7/include 
-DIBERTY_LIBRARY=/home/jgalaro/rootu7/lib/libiberty_pic.a 
-DBUILD_RTLIB_32=OFF -DCHECK_RTLIB_32=OFF

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- -- Input platform:
-- -- Attempting to automatically identify platform: aarch64-unknown-linux
-- Found LibElf: /home/jgalaro/rootu7/lib/libelf.so
-- Found LibDwarf: /home/jgalaro/rootu7/lib/libdwarf.so
-- Found libiberty: /home/jgalaro/rootu7/lib/libiberty_pic.a
-- Using libiberty /home/jgalaro/rootu7/lib/libiberty_pic.a
-- Found Thread_Db: /usr/lib/aarch64-linux-gnu/libthread_db.so
-- Disabling Boost's own CMake--known buggy in many cases
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:476 ] 
_boost_TEST_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:478 ] 
Boost_USE_MULTITHREADED = ON
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:480 ] 
Boost_USE_STATIC_LIBS =
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:482 ] 
Boost_USE_STATIC_RUNTIME = OFF
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:484 ] 
Boost_ADDITIONAL_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:486 ] 
Boost_NO_SYSTEM_PATHS = ON
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:538 ] 
Declared as CMake or Environmental Variables:
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:540 ]   
BOOST_ROOT =
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:542 ]   
BOOST_INCLUDEDIR =
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:544 ]   
BOOST_LIBRARYDIR =
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:546 ] 
_boost_TEST_VERSIONS = 
1.47;1.47.0;1.48;1.48.0;1.49;1.49.0;1.50;1.50.0;1.51;1.51.0;1.52;1.52.0;1.53;1.53.0;1.54;1.54.0;1.55;1.55.0;1.56;1.56.0;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:615 ] 
Include debugging info:
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:617 ]   
_boost_INCLUDE_SEARCH_DIRS = 
/home/jgalaro/rootu7/include;/home/jgalaro/rootu7;NO_CMAKE_SYSTEM_PATH
-- [ /home/jgalaro/cmake/share/cmake-2.8/Modules/FindBoost.cmake:619 ]   
_boost_PATH_SUFFIXES = 

Re: [DynInst_API:] getLoopHead interface in BPatch_basicBlockLoop class

[Jim Galarowicz]

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%] Building CXX object
   
libopenss-framework/CMakeFiles/openss-framework-symtabapi.dir/DyninstSymbols.cxx.o
   cd
   /u/jgalarow/OpenSpeedShop/build_mic_offline_fe/libopenss-framework
/nasa/pkgsrc/2014Q3/gcc49/bin/g++   -DHAVE_DYNINST
   -DHAVE_STDINT_H=1 -DHAVE_SYS_STAT_H=1 -DOPENSS_USE_SYMTABAPI=1
   
-DOpenSpeedShop_LIBRARY_FILE_DIR=\/nobackupp8/jgalarow/maia/pfe_ossoffline/lib64\
   -DPACKAGE=1 -DPACKAGE_VERSION=1 -DVERSION=\2.1\ -D_GNU_SOURCE
   -Dopenss_framework_symtabapi_EXPORTS -g -fPIC
   -I/u/jgalarow/OpenSpeedShop/libopenss-framework
   -I/u/jgalarow/OpenSpeedShop/build_mic_offline_fe/libopenss-framework
   -I/u/jgalarow/OpenSpeedShop/build_mic_offline_fe/libopenss-framework/offline
   -I/nasa/boost/1.50.0/include
   -I/nobackup/jgalarow/dyninst-9.0.0/include/dyninst
   -I/nobackup/jgalarow/dyninst-9.0.0/include
   -I/u/jgalarow/krellroot_v2.1u8/include
   
-I/u/jgalarow/OpenSpeedShop/build_mic_offline_fe/libopenss-framework/../libopenss-framework
   -o CMakeFiles/openss-framework-symtabapi.dir/DyninstSymbols.cxx.o -c
   /u/jgalarow/OpenSpeedShop/libopenss-framework/DyninstSymbols.cxx
   /u/jgalarow/OpenSpeedShop/libopenss-framework/DyninstSymbols.cxx: In
   function 'std::vectorLoopInfo getLoopsAt(const
   OpenSpeedShop::Framework::Address, BPatch_image)':
   /u/jgalarow/OpenSpeedShop/libopenss-framework/DyninstSymbols.cxx:140:49:
   error: 'class BPatch_basicBlockLoop' has no member named 'getLoopHead'
 BPatch_basicBlock* head = loop-getLoopHead();
 ^
   make[2]: ***
   
[libopenss-framework/CMakeFiles/openss-framework-symtabapi.dir/DyninstSymbols.cxx.o]
   Error 1
   make[2]: Leaving directory
   `/home4/jgalarow/OpenSpeedShop/build_mic_offline_fe'
   make[1]: ***
   [libopenss-framework/CMakeFiles/openss-framework-symtabapi.dir/all]
   Error 2
   make[1]: Leaving directory
   `/home4/jgalarow/OpenSpeedShop/build_mic_offline_fe'

I found this in my emails about dyninst:

Hi,

We are planing to improve our current loop detection algorithm to be 
able to handle irreducible loops. Such loops can have multiple entry 
blocks. For this matter, the original interface to get the loop head 
needs to be changed to return a vector of heads of a loop.


The involved interface is:

BPatch_basicBlock*  BPatch_basicBlockLoop::getLoopHead();

We plan to change it to:

bool 
BPatch_basicBlockLoop::getLoopHead(std::vectorBPatch_basicBlock* 
entries);


Let us know if you are using the interface and if the interface change 
will cause significant inconvenience to you.


Thanks

--Xiaozhu


However, I can't find any examples of the new getLoopHead code in the 
latest Dyninst source.   Can someone point me to it?



pfe21-101pwd
/nobackupp8/jgalarow/OpenSpeedShop_ROOT/BUILD/pfe20/dyninst-9.0.0

pfe21-94grep basicBlockLoop::getLoopHead *
pfe21-95!!/*
grep basicBlockLoop::getLoopHead */*
pfe21-96!!/*
grep basicBlockLoop::getLoopHead */*/*
pfe21-97!!/*
grep basicBlockLoop::getLoopHead */*/*/*
pfe21-98!!/*
grep basicBlockLoop::getLoopHead */*/*/*/*
pfe21-99!!/*
grep basicBlockLoop::getLoopHead */*/*/*/*/*
pfe21-100!!/*
grep basicBlockLoop::getLoopHead */*/*/*/*/*/*
pfe21-101pwd
/nobackupp8/jgalarow/OpenSpeedShop_ROOT/BUILD/pfe20/dyninst-9.0.0

pfe21-104grep getLoopHead *
pfe21-105!!/*
grep getLoopHead */*
pfe21-106!!/*
grep getLoopHead */*/*
!!/*

LOOKS LIKE THE OLD INTERFACE:

dyninstAPI/src/hybridOverwrites.C:// 
(*lIter)-getLoopHead()-getStartAddress(),
dyninstAPI/src/hybridOverwrites.C:// 
writeLoop-getLoopHead()-getStartAddress(),

pfe21-107!!/*
grep getLoopHead */*/*/*
pfe21-108!!/*
grep getLoopHead */*/*/*/*
pfe21-109!!/*
grep getLoopHead */*/*/*/*/*
pfe21-110


I need to change this to work with the new API:
cat -n /u/jgalarow/OpenSpeedShop/libopenss-framework/DyninstSymbols.cxx
...
...
  122BPatch_VectorBPatch_basicBlockLoop* loops;
   123cfg-getLoops(loops);
   124
   125for (unsigned int l = 0; l  loops.size(); ++l)
   126{
   127BPatch_basicBlockLoop* loop = loops[l];
   128
   129if ((loop == NULL) || 
!loop-containsAddressInclusive(

   130(module_base + address).getValue()
   131))
   132{
   133continue;
   134}
   135
   136// A loop containing this address has been 
found! Rejoice!
   137// And, of course, obtain the loop's head 
address and basic

   138// block address ranges...
   139
*   140BPatch_basicBlock* head = 

Re: [DynInst_API:] PATCH: have SymtabAPI properly use ELF contents to set architecture

[Jim Galarowicz]

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


module load ~/privatemodules/ossoff-maia
PBS maia96 11 !oss
osspcsamp mpiexec.hydra -host mic0 -np 30 ./nbody.mic

[openss]: pcsamp experiment using the pcsamp experiment default sampling 
rate: 100.

[openss]: pcsamp experiment calling openss.
[openss]: Setting up offline raw data directory in 
/nobackup/jgalarow/offline-oss

[openss]: Running offline pcsamp experiment using the command:
mpiexec.hydra -host mic0 -np 30 
/nobackupp8/jgalarow/maia/ossoffline/compute/bin/ossrun -c pcsamp 
./nbody.mic


/nasa/mic_knc/mic/basic/basic.2.0/bin/modulecmd: Command not found.
Iteration 1 of 50...
Iteration 2 of 50...
Iteration 3 of 50...
Iteration 4 of 50...
Iteration 5 of 50...
Iteration 6 of 50...
Iteration 7 of 50...
Iteration 8 of 50...
Iteration 9 of 50...
Iteration 10 of 50...
Iteration 11 of 50...
Iteration 12 of 50...
Iteration 13 of 50...
Iteration 14 of 50...
Iteration 15 of 50...
Iteration 16 of 50...
Iteration 17 of 50...
Iteration 18 of 50...
Iteration 19 of 50...
Iteration 20 of 50...
Iteration 21 of 50...
Iteration 22 of 50...
Iteration 23 of 50...
Iteration 24 of 50...
Iteration 25 of 50...
Iteration 26 of 50...
Iteration 27 of 50...
Iteration 28 of 50...
Iteration 29 of 50...
Iteration 30 of 50...
Iteration 31 of 50...
Iteration 32 of 50...
Iteration 33 of 50...
Iteration 34 of 50...
Iteration 35 of 50...
Iteration 36 of 50...
Iteration 37 of 50...
Iteration 38 of 50...
Iteration 39 of 50...
Iteration 40 of 50...
Iteration 41 of 50...
Iteration 42 of 50...
Iteration 43 of 50...
Iteration 44 of 50...
Iteration 45 of 50...
Iteration 46 of 50...
Iteration 47 of 50...
Iteration 48 of 50...
Iteration 49 of 50...
Iteration 50 of 50...

[openss]: Converting raw data from /nobackup/jgalarow/offline-oss into 
temp file X.0.openss


Processing raw data for nbody.mic ...
Processing processes and threads ...
Processing performance data ...
Processing symbols ...
Resolving symbols for /nobackupp8/jgalarow/demos/nbody/nbody.mic
ossutil: 
/nobackup/jgalarow/OpenSpeedShop_ROOT/BUILD/pfe20/dyninst-9.0.0/dwarf/src/dwarfHandle.C:148: 
bool Dyninst::Dwarf::DwarfHandle::init_dbg(): Assertion `0  
Unsupported archiecture in ELF file.' failed.


[openss]: Restoring and displaying default view for:
/nobackupp8/jgalarow/demos/nbody/nbody.mic-pcsamp-3.openss
[openss]: The restored experiment identifier is:  -x 1
(There are no objects specified for the basic Detail report.)


On 07/27/2015 05:14 PM, Jim Galarowicz wrote:


On 11/12/2014 03:36 PM, Bill Williams wrote:

On 11/12/2014 03:33 PM, Jim Galarowicz wrote:

Yes, I have to try to find the target version of elf.h.   The host one
must be similar to yours, it only goes to 95 as well.

On a not-quite-orthogonal note, you've run across CMake toolchain 
files (and are using them for the Dyninst pseudo-cross-compile here), 
right? That's not something we've been emphasizing in the release 
notes but it's very helpful in getting MIC stuff to behave decently.

Hi Bill,

Where are the release notes.  I saw the README.dyninst but didn't see 
any thing about cross compiling.   I'm just using Dyninst on the 
Pleiades x86_64 front-end but it is processing Intel MIC executables.


I'm back at this now for real - milestones related to the Intel MIC.  
I'm on the NASA Pleiades machine.  They now have an Intel MIC 
partition called maia.


I tried building dyninst on Pleiades to use on the FE to process 
symbols but I'm back where I was before.

That is with the abort in xxx
Processing raw data for nbody.mic ...
Processing processes and threads ...
Processing performance data ...
Processing symbols ...
Resolving symbols for /nobackupp8/jgalarow/demos/nbody/nbody.mic
ossutil: 
/nobackup/jgalarow/OpenSpeedShop_ROOT/BUILD/pfe23/dyninst-8.2.1/dwarf/src/dwarfHandle.C:139: 
bool Dyninst::Dwarf::DwarfHandle::init_dbg(): Assertion `0  
Unsupported archiecture in ELF file.' failed.


...



PBS maia96 37 vi 
/nobackup/jgalarow/OpenSpeedShop_ROOT/BUILD/pfe23/dyninst-8.2.1/dwarf/src/dwarfHandle.C



I've downloaded the latest dyninst using: alias git_dyninst='git clone 
http://git.dyninst.org/dyninst.git'

and I'm going to try this version to see if there is any difference.


Thanks,
Jim G

Here is the objdump -i for the Intel MIC binary if that sheds any light.

qsub -q mic_knc -I
qsub: waiting for job 4369498.pbspl1.nas.nasa.gov to start
qsub: job 4369498.pbspl1.nas.nasa.gov ready

Job 4369498.pbspl1.nas.nasa.gov started on Mon Jul 27 12:33:36 PDT 2015
The job requested the following resources:
ncpus=1
place=pack
walltime=01:00:00

PBS set the following environment variables:
FORT_BUFFERED = 1
   TZ = PST8PDT

On maia96:
in setting path code
unsetenv

[DynInst_API:] Compile issue building Dyninst on ORNL titan

[Jim Galarowicz]

Hi,

I'm getting these types of errors when trying to build Dyninst on the 
ORNL Titan Cray.
It looks to me like this shouldn't happen, as the INT32_MAX and other 
defines are in /usr/include/stdint.h and Types.h includes stdint.h.

Any ideas on why these errors are showing up?

Thanks,
Jim G

/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h: 
In function 'bool NS_x86::is_disp32(long int)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:158:18: 
error: 'INT32_MAX' was not declared in this scope

 #define I32_MAX  INT32_MAX
  ^

jgalaro@titan-ext6:~/OpenSpeedShop_ROOT grep INT32_MAX /usr/include/*
/usr/include/stdint.h:# define INT32_MAX(2147483647)
/usr/include/stdint.h:# define UINT32_MAX(4294967295U)
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT cd BUILD/titan-ext6/dyninst-8.2.0/
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0 
grep stdint.h 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/*
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0 
grep INT32_MIN  /usr/include/*

/usr/include/stdint.h:# define INT32_MIN(-2147483647-1)
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0



Linking CXX shared library libpatchAPI.so
[ 39%] Built target patchAPI
Scanning dependencies of target dyninstAPI
[ 39%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/BPatch.C.o
In file included from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/headers.h:53:0,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Timer.h:43,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/stats.h:38,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/dyninstAPI/src/BPatch.C:43:
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/fraction.h: 
In constructor 'fraction::fraction(int64_t)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:140:28: 
error: 'INT64_C' was not declared in this scope

 #define I64_C(x)  INT64_C(x)
^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/fraction.h:59:50: 
note: in expansion of macro 'I64_C'

   explicit fraction(int64_t n) : numer(n), denom(I64_C(1))  {
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h: 
In function 'bool NS_x86::is_disp32(long int)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:158:18: 
error: 'INT32_MAX' was not declared in this scope

 #define I32_MAX  INT32_MAX
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h:907:19: 
note: in expansion of macro 'I32_MAX'

   return (disp = I32_MAX  disp = I32_MIN);
   ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:159:18: 
error: 'INT32_MIN' was not declared in this scope

 #define I32_MIN  INT32_MIN
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h:907:38: 
note: in expansion of macro 'I32_MIN'

   return (disp = I32_MAX  disp = I32_MIN);
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h: 
In function 'bool NS_x86::is_addr32(Dyninst::Address)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:160:18: 
error: 'UINT32_MAX' was not declared in this scope

 #define UI32_MAX UINT32_MAX
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h:913:20: 
note: in expansion of macro 'UI32_MAX'

 return (addr  UI32_MAX);
^
In file included from 
/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/system/system_error.hpp:14:0,
 from 
/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/exceptions.hpp:22,
 from 
/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/pthread/thread_data.hpp:10,
 from 
/lustre/atlas/proj-shared/csc103/jgalaro/boost_1.53.0/include/boost/thread/pthread/condition_variable.hpp:12,
 from 

Re: [DynInst_API:] Compile issue building Dyninst on ORNL titan

[Jim Galarowicz]

I'm not sure if the patchAPI compile options have the correct defines 
set or is there a compile option that is required to get the constants 
recognized?
I put the #include stdint.h into BPatch.C to see if the Dyninst build 
was missing including stdint.h because it is enclosed in some if 
defined type code.
So, I'm guessing there is an missing option or missing compiler define 
that is needed.


From stdint.h on Titan:

/* The ISO C99 standard specifies that in C++ implementations these
   macros should only be defined if explicitly requested.  */
#if !defined __cplusplus || defined __STDC_LIMIT_MACROS

# if __WORDSIZE == 64
#  define __INT64_C(c)  c ## L
#  define __UINT64_C(c) c ## UL
# else
#  define __INT64_C(c)  c ## LL
#  define __UINT64_C(c) c ## ULL
# endif

Build snippet where the compile errors are located:

[ 47%] Built target patchAPI
Scanning dependencies of target dyninstAPI
[ 47%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/BPatch.C.o
In file included from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/headers.h:53:0,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/Timer.h:43,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/stats.h:38,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/dyninstAPI/src/BPatch.C:45:
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/fraction.h: 
In constructor 'fraction::fraction(int64_t)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/Types.h:140:28: 
error: 'INT64_C' was not declared in this scope

 #define I64_C(x)  INT64_C(x)
^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/fraction.h:59:50: 
note: in expansion of macro 'I64_C'

   explicit fraction(int64_t n) : numer(n), denom(I64_C(1))  {
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/arch-x86.h: 
In function 'bool NS_x86::is_disp32(long int)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/Types.h:158:18: 
error: 'INT32_MAX' was not declared in this scope

 #define I32_MAX  INT32_MAX
  ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/arch-x86.h:907:19: 
note: in expansion of macro 'I32_MAX'

   return (disp = I32_MAX  disp = I32_MIN);
   ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2/common/src/Types.h:159:18: 
error: 'INT32_MIN' was not declared in this scop

On 10/17/2014 09:22 AM, Jim Galarowicz wrote:

Hi,

I'm getting these types of errors when trying to build Dyninst on the 
ORNL Titan Cray.
It looks to me like this shouldn't happen, as the INT32_MAX and other 
defines are in /usr/include/stdint.h and Types.h includes stdint.h.

Any ideas on why these errors are showing up?

Thanks,
Jim G

/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/arch-x86.h: 
In function 'bool NS_x86::is_disp32(long int)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:158:18: 
error: 'INT32_MAX' was not declared in this scope

 #define I32_MAX  INT32_MAX
  ^

jgalaro@titan-ext6:~/OpenSpeedShop_ROOT grep INT32_MAX /usr/include/*
/usr/include/stdint.h:# define INT32_MAX(2147483647)
/usr/include/stdint.h:# define UINT32_MAX(4294967295U)
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT cd 
BUILD/titan-ext6/dyninst-8.2.0/
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0 grep 
stdint.h 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/*
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Types.h:#include 
stdint.h
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0 grep 
INT32_MIN  /usr/include/*

/usr/include/stdint.h:# define INT32_MIN(-2147483647-1)
jgalaro@titan-ext6:~/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0



Linking CXX shared library libpatchAPI.so
[ 39%] Built target patchAPI
Scanning dependencies of target dyninstAPI
[ 39%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/BPatch.C.o
In file included from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/headers.h:53:0,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst-8.2.0/common/src/Timer.h:43,
 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext6/dyninst

[DynInst_API:] What level of boost is needed to build Dyninst?

[Jim Galarowicz]

Hi Dyninst team,

I'm getting these compile errors on spirit at a DOD site.   The compiler is 
4.7.3.

What level of boost is needed to build Dyninst?   This system has boost-1.41:
ash-4.1$ rpmq boost
perfboost-1.10-sgi710r6.rhel6.x86_64
boost-regex-1.41.0-18.el6.x86_64
boost-1.41.0-18.el6.x86_64
boost-devel-1.41.0-18.el6.x86_64
boost-wave-1.41.0-18.el6.x86_64
boost-program-options-1.41.0-18.el6.x86_64
boost-date-time-1.41.0-18.el6.x86_64
boost-serialization-1.41.0-18.el6.x86_64
boost-signals-1.41.0-18.el6.x86_64
boost-filesystem-1.41.0-18.el6.x86_64
boost-thread-1.41.0-18.el6.x86_64
boost-python-1.41.0-18.el6.x86_64
boost-system-1.41.0-18.el6.x86_64
boost-graph-1.41.0-18.el6.x86_64
boost-test-1.41.0-18.el6.x86_64
boost-math-1.41.0-18.el6.x86_64
boost-iostreams-1.41.0-18.el6.x86_64
bash-4.1$ 


[  3%] Building CXX object common/CMakeFiles/common.dir/src/util.C.o
[  3%] Building CXX object common/CMakeFiles/common.dir/src/Node.C.o
In file included from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/Node.C:35:0:
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/Edge.h: 
In member function 'virtual Dyninst::Edge::Ptr Dyninst::EdgeIteratorSet::get()':
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/Edge.h:138:39:
 error: use of deleted function 
'boost::shared_ptrDyninst::Edge::shared_ptr(const 
boost::shared_ptrDyninst::Edge)'
In file included from /usr/include/boost/shared_ptr.hpp:17:0,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/dyn_regs.h:36,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/dyntypes.h:163,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/Graph.h:37,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/Node.C:34:
/usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: 
'boost::shared_ptrDyninst::Edge::shared_ptr(const 
boost::shared_ptrDyninst::Edge)' is implicitly declared as deleted because 
'boost::shared_ptrDyninst::Edge' declares a move constructor or move 
assignment operator
In file included from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/Node.C:39:0:
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:
 In member function 'virtual Dyninst::Node::Ptr 
Dyninst::NodeIteratorSet::get()':
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:60:39:
 error: use of deleted function 
'boost::shared_ptrDyninst::Node::shared_ptr(const 
boost::shared_ptrDyninst::Node)'
In file included from /usr/include/boost/shared_ptr.hpp:17:0,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/dyn_regs.h:36,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/dyntypes.h:163,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/h/Graph.h:37,
 from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/Node.C:34:
/usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: 
'boost::shared_ptrDyninst::Node::shared_ptr(const 
boost::shared_ptrDyninst::Node)' is implicitly declared as deleted because 
'boost::shared_ptrDyninst::Node' declares a move constructor or move 
assignment operator
In file included from 
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/Node.C:39:0:
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:
 In member function 'virtual Dyninst::Node::Ptr 
Dyninst::NodeSearchIterator::get()':
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:179:38:
 error: use of deleted function 
'boost::shared_ptrDyninst::Node::shared_ptr(const 
boost::shared_ptrDyninst::Node)'
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:
 In member function 'virtual Dyninst::NodeIteratorImpl* 
Dyninst::NodeSearchIterator::copy()':
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:196:82:
 error: use of deleted function 
'boost::shared_ptrDyninst::Node::shared_ptr(const 
boost::shared_ptrDyninst::Node)'
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:206:5:
 error:   initializing argument 1 of 
'Dyninst::NodeSearchIterator::NodeSearchIterator(Dyninst::Node::Ptr, 
Dyninst::NodeSearchIterator::Direction, Dyninst::NodeSearchIterator::Type, 
std::dequeboost::shared_ptrDyninst::Node , 
std::setboost::shared_ptrDyninst::Node )'
/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2.0/common/src/NodeIterator.h:
 In constructor 
'Dyninst::NodeSearchIterator::NodeSearchIterator(Dyninst::Node::Ptr, 
Dyninst::NodeSearchIterator::Direction, Dyninst::NodeSearchIterator::Type)':

Re: [DynInst_API:] Building Dyninst 8.2 on SGI ICE - issue

[Jim Galarowicz]

Hi Bill,

I'm running into this problem again with the release dyninst-8.2 sources 
on the ORNL Titan Cray platform.


[  6%] Building CXX object 
common/CMakeFiles/common.dir/src/addrtranslate-auxv.C.o
[  6%] Building CXX object 
common/CMakeFiles/common.dir/src/addrtranslate-linux.C.o

Linking CXX shared library libcommon.so
/usr/bin/ld: 
/lustre/atlas/proj-shared/csc103/jgalaro/krellroot_v2.1u5/lib64/libiberty.a(cplus-dem.o): 
relocation R_X86_64_32S against `_sch_istable' can not be used when 
making a shared object; recompile with -fPIC
/lustre/atlas/proj-shared/csc103/jgalaro/krellroot_v2.1u5/lib64/libiberty.a: 
could not read symbols: Bad value

collect2: error: ld returned 1 exit status
make[2]: *** [common/libcommon.so.8.2.0] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2


In dyninst-8.2.0/dyninstAPI_RT the CMakeLists.txt has these references, 
but there doesn't appear to be a way to turn the 32 bit build off w/o 
creating a patch.


CMakeLists.txt:set (SRC_LIST_mabi ${SRC_LIST} ${SRC_LIST_i386})
CMakeLists.txt:set (SRC_LIST_mabi ${SRC_LIST} ${SRC_LIST_ppc32})
CMakeLists.txt:if (SRC_LIST_mabi)
CMakeLists.txt:add_library (dyninstAPI_RT_m32 SHARED ${SRC_LIST_mabi})
CMakeLists.txt:add_library (dyninstAPI_RT_m32_static STATIC 
${SRC_LIST_mabi})


Is there a way and I'm missing it?

Thanks,
Jim G


On 03/26/2014 02:37 PM, Bill Williams wrote:

On 03/26/2014 01:36 PM, Jim Galarowicz wrote:

Hi all,

If I do a module purge, that apparently gets rid of the intel library 
business with as.

However, now I've arrived at another issue.

Does this version of Dyninst honor the
   make SKIP_BUILD_RTLIB_32=1

variable?  It doesn't look like it.   I searched for CMAKE variables 
with SKIP in them but didn't see any.


Or else I could build my own binutils with fPIC.

Is there a way to turn off the 32 bit generation with CMAKE?

If you poke at the RTlib's CMakeLists.txt, you'll see that we disable 
32-bit generation if a) a compile test of some stripe fails, or b) 
we're on BlueGene. As an intermediate step, you can throw in an 
additional clause of or we told you not to build this.


It is on my list (though not next on my list) to poke at the compile 
test there and see if I can discern why it is insufficient to actually 
detect whether we can/should build a 32-bit runtime. Anyone who 
has/gets any insight there, I'd love to hear it...


--bw


Thanks,
Jim G



Build dyninst? y/n


Build-RPM command-line argument #1 = dyninst-8.2
Build-RPM command-line argument #2 =
Build-RPM command-line argument #3 =

DEBUG: Setting machine to uname: spirit01
RPM working directory: spirit01
Environment variable KRELL_ROOT_PREFIX is set
Environment variable KRELL_ROOT_PREFIX is set to 
/home/galarowi/krellroot_v2.1u3

error: Macro %target_prefix has empty body
error: Macro %target_prefix has empty body
Executing(%prep): /bin/sh -e 
/home/galarowi/OpenSpeedShop_ROOT/INSTALL/spirit01/rpm-tmp.vognqG

+ umask 022
+ cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d dyninst-8.2 ']'
+ rm -fr dyninst-8.2
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3/include -a -f 
/home/galarowi/krellroot_v2.1u3/include/boost/shared_ptr.hpp ']'

+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/boost/shared_ptr.hpp ']'
+ export DYNINST_BOOST_ROOT=
+ DYNINST_BOOST_ROOT=
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'

+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3//libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3//libelf.a ']'

+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'

+ export LIBELFDIR=/usr
+ LIBELFDIR=/usr
+ '[' -f /usr/include/libelf.h ']'
+ export LIBELFINC=/usr/include
+ LIBELFINC=/usr/include
+ '[' '!' -z ']'
+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libdwarf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libdwarf.a ']'

+ export LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
+ LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
+ '[' '!' -z /app/wpostool/COST/binutils-2.23 ']'
+ '[' -f /app/wpostool/COST/binutils-2.23/lib64/libiberty.a ']'
+ export 
LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a

+ LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
+ cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
+ rm -rf dyninst-8.2
+ /usr/bin/gzip -dc 
/home/galarowi/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.tar.gz

+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd dyninst-8.2
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch (dyninst-8.2.patch):'
Patch (dyninst-8.2

Re: [DynInst_API:] Build error dyninst-8.2 - /usr/bin/ld: cannot find -lLINK_PRIVATE

[Jim Galarowicz]

Hi Josh, Bill, all,

I switched back to 8.1.2 on rzmerl for this particular build and it 
seems to be working.

I will try the new version again when the new code becomes available to me.

Thanks,
Jim G

On 06/19/2014 11:48 AM, Josh Stone wrote:

On 06/19/2014 11:34 AM, Jim Galarowicz wrote:

Currently, I'm using the official release for 8.2.

That was my point - there's no such thing yet.  The v8.2 branch is
currently in development towards a release, but it's not finished.  I
expect the tag will be called v8.2.0 when it's official.


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

[DynInst_API:] Build error dyninst-8.2 - /usr/bin/ld: cannot find -lLINK_PRIVATE

[Jim Galarowicz]

Hi all,

I'm getting a build error on rzmerl at LLNL when trying to build the 
release version of 8.2.


The message I'm getting:

Linking CXX shared library libcommon.so
/usr/bin/ld: cannot find -lLINK_PRIVATE
collect2: ld returned 1 exit status
make[2]: *** [common/libcommon.so.8.2.0] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2

What I get when I grep for  LINK_PRIVATE in the build area, which seems 
to point to libiberty.Do you see anything obviously wrong?  Seems 
like it is finding libiberty.a and it exists.


rzmerl156{jeg}88: grep LINK_PRIVATE BUILD/rzmerl156/dyninst-8.2/*
BUILD/rzmerl156/dyninst-8.2/CMakeCache.txt:common_LIB_DEPENDS:STATIC=general;LINK_PRIVATE;general;/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty.a;
rzmerl156{jeg}89: !!/*
grep LINK_PRIVATE BUILD/rzmerl156/dyninst-8.2/*/*
BUILD/rzmerl156/dyninst-8.2/common/CMakeLists.txt:target_link_libraries 
(common LINK_PRIVATE ${IBERTY_LIBRARY})
rzmerl156{jeg}90: lsr 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty.a
504 -rw--- 1 jeg jeg 509756 Jun 18 13:00 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty.a

rzmerl156{jeg}91:




THE TOTAL BUILD OUTPUT:


+ echo 'Build dyninst? y/n'
Build dyninst? y/n
+ echo

+ '[' 9 = 9 -o 0 == 0 ']'
+ answer=Y
+ '[' Y = Y -o Y = y ']'
+ '[' 0 == 0 ']'
+ '[' 0 == 0 ']'
+ '[' 0 == 0 ']'
+ '[' 1 = 1 ']'
+ '[' krellroot == mrnet ']'
+ '[' krellroot == krellroot ']'
+ rm -rf RPMS/rzmerl156/dyninst.OSS.x86_64.rpm
+ ./Build-RPM-krellroot dyninst-8.2

Build-RPM command-line argument #1 = dyninst-8.2
Build-RPM command-line argument #2 =
Build-RPM command-line argument #3 =

DEBUG: Setting machine to uname: rzmerl156
RPM working directory: rzmerl156
passTargetArch= x86_64
hostarch= x86_64
Environment variable KRELL_ROOT_PREFIX is set
Environment variable KRELL_ROOT_PREFIX is set to 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot
Executing(%prep): /bin/sh -e 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/INSTALL/rzmerl156/rpm-tmp.fKkmMc

+ umask 022
+ cd 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzmerl156

+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d dyninst-8.2 ']'
+ rm -fr dyninst-8.2
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/include 
-a -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/include/boost/shared_ptr.hpp 
']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/boost/shared_ptr.hpp 
']'

+ export DYNINST_BOOST_ROOT=
+ DYNINST_BOOST_ROOT=
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' '!' -z 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libelf.so 
-o -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libelf.a 
']'
+ '[' '!' -z 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot//libelf.so 
-o -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot//libelf.a 
']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libelf.so 
-o -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libelf.a 
']'

+ export LIBELFDIR=/usr
+ LIBELFDIR=/usr
+ '[' -f /usr/include/libelf.h ']'
+ export LIBELFINC=/usr/include
+ LIBELFINC=/usr/include
+ '[' '!' -z 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libdwarf.so 
-o -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libdwarf.a 
']'
+ export 
LIBDWARFDIR=/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot
+ 
LIBDWARFDIR=/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot
+ '[' '!' -z 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty_pic.a 
']'
+ '[' '!' -z 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty_pic.a 
']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib64/libiberty_pic.a 
']'
+ '[' -d 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot ']'
+ '[' -f 
/collab/usr/global/tools/openspeedshop/oss-dev/oss_kestral_kroot/lib/libiberty_pic.a 
']'

+ '[' -f /usr/lib/libiberty_pic.a ']'

+ 

Re: [DynInst_API:] Several Dyninst build issues

[Jim Galarowicz]

/openspeedshop-2.1/libopenss-queries/.libs/libopenss-queries.so
  
 /home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1/libopenss-framework/.libs/libopenss-framework.so
  
 /home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1/libltdl/.libs/libltdl.so
  /home/etijskens/software/oss-2.1/lib/libsqlite3.so -lrt -liberty_pic 
 ../libltdl/.libs/libltdl.so -L/usr/lib -lz -lgomp -lpthread -lutil -ldl 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.8 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu 
 -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
 -L/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64 
 -L/opt/intel/composer_xe_2013_sp1.2.144/ipp/../compiler/lib/intel64 
 -L/opt/intel/composer_xe_2013_sp1.2.144/ipp/lib/intel64 
 -L/opt/intel/composer_xe_2013_sp1.2.144/mkl/lib/intel64 
 -L/opt/intel/composer_xe_2013_sp1.2.144/tbb/lib/intel64/gcc4.4 
 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lstdc++ -lm -lc -lgcc_s 
 /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o 
 /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
 -fopenmp -Wl,-soname -Wl,libopenss-cli.so.0 -o .libs/libopenss-cli.so.0.0.0
 /usr/bin/ld: cannot find -lz
 collect2: error: ld returned 1 exit status
 make[3]: *** [libopenss-cli.la] Error 1
 make[3]: Leaving directory 
 `/home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1/libopenss-cli'
 make[2]: *** [all] Error 2
 make[2]: Leaving directory 
 `/home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1/libopenss-cli'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory 
 `/home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1'
 make: *** [all] Error 2
 error: Bad exit status from 
 /home/etijskens/software/openspeedshop-release-2.1/INSTALL/bert-MacBookPro-ubuntu/rpm-tmp.cDbJ56
  (%build)
 
 
 RPM build errors:
 Bad exit status from 
 /home/etijskens/software/openspeedshop-release-2.1/INSTALL/bert-MacBookPro-ubuntu/rpm-tmp.cDbJ56
  (%build)
 OpenSpeedShop FAILED TO BUILD - TERMINATING BUILD SCRIPT.  Please check for 
 errors.
 
 
 On 17/04/14 20:32, Jim Galarowicz wrote:
 Hi Bill,
 
 I think I have all the issues addressed based on your suggestions.   I ran 
 into another similar (to issue 2) problem today on Pleiades at NASA where 
 the binutils as assembler was getting invoked and cause xerces-c to file to 
 configure.  So, I've changed our binutils build to not install the bin tools 
 (ld, ar, as, etc.).  
 
 Also, I'm not seeing any checks that our OSS build is doing that would let 
 libdwarf.a be recognised as an acceptable dwarf installation.  We seem to be 
 only checking for libdwarf.so and will build a shared version of libdwarf if 
 we don't find libdwarf.so.   I thought we were checking for libdwarf.a and 
 allowing that to satisfy the requirement.  So, I may need more information 
 from Engelbert on the libdwarf installed on his platform to see why the 
 issue 3 is happening.
 
 For BG/Q, I put in a check to see if we are on a BG machine and then 
 switching the version of dyninst to 8.1.2.  This bloats the source directory 
 a bit, but should be ok for a while.
 
 I have put out a new tarball ( rc2-openspeedshop-release-2.1-u3.tar.gz ) on 
 sourceforge for Engelbert and others to try.
 
 Thanks for your help.
 
 Jim G
 
 On 04/14/2014 09:09 AM, Bill Williams wrote:
 Jim-- 
 
 Trimming things down to issues that remain open w.r.t. 8.2: 
 
  2) Does /opt/krellroot_v2.1u3/bin/ld work for linking object files 
 built with gcc? Is this the linker you intend to use? You're mixing 
 toolchains here (that linker with /usr/bin/gcc) and I have no idea 
 whether that's deliberate or not, and no idea whether the toolchains 
 in question are compatible. 
 I don't know exactly what to do with this.  If I need to install 
 binutils, then it is in the krellroot which is used to reference other 
 needed components that might not be installed.  ld gets installed into 
 the krellroot when binutils is built.   You are correct, though. 
 Manually moving ld to ld-back and rerunning the dyninst build allows it 
 to succeed. 
 
 I am presuming that you need various binutils components as direct O|SS 
 dependencies and not just as Dyninst depedencies here. IIRC it's possible 
 to coerce binutils into building each of its components separately, though 
 coerce is absolutely the right verb--unless my memory is slipping, we do 
 this for libiberty. I can see three general approaches here: 
 
 1) Only build the binutils components you need 
 2) Prune the binutils install to the set of components you need 
 3) Add the krell auxiliary directories at the end, rather than the 
 beginning, of the assorted path variables (assuming that the goal is to 
 augment what's available

[DynInst_API:] Building Dyninst 8.2 on SGI ICE - issue

[Jim Galarowicz]

Hi,

I'm now trying to build Dyninst 8.2 on an SGI ICE system.  But I'm getting this:
  CMake Error at 
/work1/app/gnu/platforms/x86_64/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61
 (message):
  The C compiler /app/gmpapp/gcc/platform/gcc-4.7.3/bin/gcc is not able to
  compile a simple test program.

[galarowi@spirit01 OpenSpeedShop_ROOT ]$ cmake --version
cmake version 2.8.10.2
[galarowi@spirit01 OpenSpeedShop_ROOT ]$ gcc --version
gcc (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[galarowi@spirit01 OpenSpeedShop_ROOT ]$ which CC
/usr/bin/which: no CC in 
(/app/gmpapp/gcc/platform/gcc-4.7.3/bin:/home/galarowi/bin:/opt/local/bin:/opt/cisco/vpn/bin:/usr/local/usp/git/1.8.5/bin:/usr/local/usp/PETtools/CE/pkgs/cmake-2.8.11.2/bin:.:/usr/local/krb5/bin:/usr/local/ossh/bin:/opt/sgi/mpt/mpt-2.08/bin:/usr/lib64/qt-3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/opt/c3/bin:/opt/pbs/default/bin:/opt/sgi/sbin:/opt/sgi/bin:/home/galarowi/bin:/home/galarowi/bin/x86_64:/hafs_x86_64:/hafs_x86_64/bin:/usr/bin/X11:/usr/local/bin:/app/java/jdk1.7.0_17/bin:.)
[galarowi@spirit01 OpenSpeedShop_ROOT ]$ which CXX
/usr/bin/which: no CXX in 
(/app/gmpapp/gcc/platform/gcc-4.7.3/bin:/home/galarowi/bin:/opt/local/bin:/opt/cisco/vpn/bin:/usr/local/usp/git/1.8.5/bin:/usr/local/usp/PETtools/CE/pkgs/cmake-2.8.11.2/bin:.:/usr/local/krb5/bin:/usr/local/ossh/bin:/opt/sgi/mpt/mpt-2.08/bin:/usr/lib64/qt-3.3/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/opt/c3/bin:/opt/pbs/default/bin:/opt/sgi/sbin:/opt/sgi/bin:/home/galarowi/bin:/home/galarowi/bin/x86_64:/hafs_x86_64:/hafs_x86_64/bin:/usr/bin/X11:/usr/local/bin:/app/java/jdk1.7.0_17/bin:.)


[galarowi@spirit01 OpenSpeedShop_ROOT ]$ module list
Currently Loaded Modulefiles:
  1) mpt/2.08   3) /app/startup/shell.module  5) 
/app/startup/chgaccnt.module   7) /app/startup/login2.module
  2) costinit   4) /app/startup/alias.module  6) 
/app/startup/login.module  8) gcc-compilers/4.7.3

[galarowi@spirit01 OpenSpeedShop_ROOT ]$ uname -a
Linux spirit01 2.6.32-358.11.1.el6.x86_64 #1 SMP Wed May 15 10:48:38 EDT 2013 
x86_64 x86_64 x86_64 GNU/Linux

Do you have any advice on what might be causing this?

Thanks,
Jim G


The complete build output:

~/OpenSpeedShop_ROOT/BUILD/spirit01 ~/OpenSpeedShop_ROOT
~/OpenSpeedShop_ROOT
XERCESC BUILT SUCCESSFULLY.

Build vampirtrace? y/n

Build dyninst? y/n


Build-RPM command-line argument #1 = dyninst-8.2
Build-RPM command-line argument #2 = 
Build-RPM command-line argument #3 = 

DEBUG: Setting machine to uname: spirit01
RPM working directory: spirit01
Environment variable KRELL_ROOT_PREFIX is set
Environment variable KRELL_ROOT_PREFIX is set to /home/galarowi/krellroot_v2.1u3
error: Macro %target_prefix has empty body
error: Macro %target_prefix has empty body
Executing(%prep): /bin/sh -e 
/home/galarowi/OpenSpeedShop_ROOT/INSTALL/spirit01/rpm-tmp.M7pyFg
+ umask 022
+ cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d dyninst-8.2 ']'
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3/include -a -f 
/home/galarowi/krellroot_v2.1u3/include/boost/shared_ptr.hpp ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/boost/shared_ptr.hpp ']'
+ export DYNINST_BOOST_ROOT=
+ DYNINST_BOOST_ROOT=
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'
+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3//libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3//libelf.a ']'
+ '[' -d /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'
+ export LIBELFDIR=/usr
+ LIBELFDIR=/usr
+ '[' -f /usr/include/libelf.h ']'
+ export LIBELFINC=/usr/include
+ LIBELFINC=/usr/include
+ '[' '!' -z ']'
+ '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
+ '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libdwarf.so -o -f 
/home/galarowi/krellroot_v2.1u3/lib64/libdwarf.a ']'
+ export LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
+ LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
+ '[' '!' -z /app/wpostool/COST/binutils-2.23 ']'
+ '[' -f /app/wpostool/COST/binutils-2.23/lib64/libiberty.a ']'
+ export LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
+ LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
+ cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
+ rm -rf dyninst-8.2
+ /usr/bin/gzip -dc /home/galarowi/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.tar.gz
+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd dyninst-8.2
+ 

Re: [DynInst_API:] Building Dyninst 8.2 on SGI ICE - issue

[Jim Galarowicz]

Hi all,

I built my own binutils and the Dyninst build worked.
Just thought I'd provide that status.

Thanks for your time!

Jim G

On Mar 26, 2014, at 11:36 AM, Jim Galarowicz wrote:

 Hi all,
 
 If I do a module purge, that apparently gets rid of the intel library 
 business with as.
 However, now I've arrived at another issue.
 
 Does this version of Dyninst honor the 
  make SKIP_BUILD_RTLIB_32=1
 
 variable?  It doesn't look like it.   I searched for CMAKE variables with 
 SKIP in them but didn't see any.
 
 Or else I could build my own binutils with fPIC.
 
 Is there a way to turn off the 32 bit generation with CMAKE?
 
 Thanks,
 Jim G
 
 
 
 Build dyninst? y/n
 
 
 Build-RPM command-line argument #1 = dyninst-8.2
 Build-RPM command-line argument #2 = 
 Build-RPM command-line argument #3 = 
 
 DEBUG: Setting machine to uname: spirit01
 RPM working directory: spirit01
 Environment variable KRELL_ROOT_PREFIX is set
 Environment variable KRELL_ROOT_PREFIX is set to 
 /home/galarowi/krellroot_v2.1u3
 error: Macro %target_prefix has empty body
 error: Macro %target_prefix has empty body
 Executing(%prep): /bin/sh -e 
 /home/galarowi/OpenSpeedShop_ROOT/INSTALL/spirit01/rpm-tmp.vognqG
 + umask 022
 + cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
 + LANG=C
 + export LANG
 + unset DISPLAY
 + '[' -d dyninst-8.2 ']'
 + rm -fr dyninst-8.2
 + '[' '!' -z ']'
 + '[' '!' -z ']'
 + '[' -d /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -d /home/galarowi/krellroot_v2.1u3/include -a -f 
 /home/galarowi/krellroot_v2.1u3/include/boost/shared_ptr.hpp ']'
 + '[' -d /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -f /home/galarowi/krellroot_v2.1u3/boost/shared_ptr.hpp ']'
 + export DYNINST_BOOST_ROOT=
 + DYNINST_BOOST_ROOT=
 + '[' '!' -z ']'
 + '[' '!' -z ']'
 + '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
 /home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'
 + '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -f /home/galarowi/krellroot_v2.1u3//libelf.so -o -f 
 /home/galarowi/krellroot_v2.1u3//libelf.a ']'
 + '[' -d /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libelf.so -o -f 
 /home/galarowi/krellroot_v2.1u3/lib64/libelf.a ']'
 + export LIBELFDIR=/usr
 + LIBELFDIR=/usr
 + '[' -f /usr/include/libelf.h ']'
 + export LIBELFINC=/usr/include
 + LIBELFINC=/usr/include
 + '[' '!' -z ']'
 + '[' '!' -z /home/galarowi/krellroot_v2.1u3 ']'
 + '[' -f /home/galarowi/krellroot_v2.1u3/lib64/libdwarf.so -o -f 
 /home/galarowi/krellroot_v2.1u3/lib64/libdwarf.a ']'
 + export LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
 + LIBDWARFDIR=/home/galarowi/krellroot_v2.1u3
 + '[' '!' -z /app/wpostool/COST/binutils-2.23 ']'
 + '[' -f /app/wpostool/COST/binutils-2.23/lib64/libiberty.a ']'
 + export LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
 + LIBIBERTYLIBDIR=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
 + cd /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01
 + rm -rf dyninst-8.2
 + /usr/bin/gzip -dc 
 /home/galarowi/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.tar.gz
 + /bin/tar -xf -
 + STATUS=0
 + '[' 0 -ne 0 ']'
 + cd dyninst-8.2
 + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
 + echo 'Patch (dyninst-8.2.patch):'
 Patch (dyninst-8.2.patch):
 + /bin/cat /home/galarowi/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.patch
 + /usr/bin/patch -p1 --fuzz=0
 (Stripping trailing CRs from patch.)
 patching file CMakeLists.txt
 + pwd
 /home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2
 + export 
 DYNINST_ROOT=/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2
 + DYNINST_ROOT=/home/galarowi/OpenSpeedShop_ROOT/BUILD/spirit01/dyninst-8.2
 + '[' '%{target_prefix}' == bgp ']'
 + '[' '%{target_prefix}' == bgq ']'
 + CXXFLAGS=-std=c++0x
 + cmake . 
 -DCMAKE_INSTALL_PREFIX=/home/galarowi/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/home/galarowi/krellroot_v2.1u3
  
 -DINSTALL_LIB_DIR=/home/galarowi/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/home/galarowi/krellroot_v2.1u3/lib64
  
 -DINSTALL_INCLUDE_DIR=/home/galarowi/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/home/galarowi/krellroot_v2.1u3/include/dyninst
  
 -DCMAKE_PREFIX_PATH=/home/galarowi/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/home/galarowi/krellroot_v2.1u3
  -DCMAKE_BUILD_TYPE=RelWithDebInfo 
 -DLIBDWARF_LIBRARIES=/home/galarowi/krellroot_v2.1u3/lib64 
 -DLIBDWARF_INCLUDE_DIR=/home/galarowi/krellroot_v2.1u3/include 
 -DLIBELF_LIBRARIES=/usr/lib64 -DLIBELF_INCLUDE_DIR=/usr/include -DPATH_BOOST= 
 -DIBERTY_LIBRARY=/app/wpostool/COST/binutils-2.23/lib64/libiberty.a
 -- The C compiler identification is GNU 4.4.7
 -- The CXX compiler identification is GNU 4.4.7
 -- Check for working C compiler: /usr/bin/cc
 -- Check for working C compiler: /usr/bin/cc -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Check for working CXX compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting

[DynInst_API:] Building DyninstAPI on BG/Q

[Jim Galarowicz]

Hi all,

I'm trying to build DyninstAPI on the FE of a BG/Q.   I'm getting an 
assembly error.
Can anyone see if I'm doing something wrong or if there is a build issue 
in Dyninst?


Thanks,
Jim G


+ exit 0
VAMPIRTRACE BUILT SUCCESSFULLY.
Build dyninst? y/n


Build-RPM command-line argument #1 = dyninst-8.2
Build-RPM command-line argument #2 =
Build-RPM command-line argument #3 =

DEBUG: Setting machine to OPENSS_TARGET_ARCH: rzuseqlac2
RPM working directory: rzuseqlac2
Environment variable KRELL_ROOT_PREFIX is set
Environment variable KRELL_ROOT_PREFIX is set to 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3
Executing(%prep): /bin/sh -e 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/INSTALL/rzuseqlac2/rpm-tmp.UiXNdk

+ umask 022
+ cd 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2

+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d dyninst-8.2 ']'
+ rm -fr dyninst-8.2
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -d 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/include -a -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/include/boost/shared_ptr.hpp 
']'

+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/boost/shared_ptr.hpp 
']'

+ export DYNINST_BOOST_ROOT=
+ DYNINST_BOOST_ROOT=
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.so 
-o -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.a ']'

+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3//libelf.so -o 
-f /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3//libelf.a ']'

+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.so 
-o -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.a ']'

+ export LIBELFDIR=/usr
+ LIBELFDIR=/usr
+ '[' -f /usr/include/libelf.h ']'
+ export LIBELFINC=/usr/include
+ LIBELFINC=/usr/include
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libdwarf.so 
-o -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libdwarf.a ']'
+ export 
LIBDWARFDIR=/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3

+ LIBDWARFDIR=/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3
+ '[' '!' -z ']'
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libiberty.a 
']'

+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libiberty.a 
']'

+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f 
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib/libiberty.a ']'

+ '[' -f /usr/lib/libiberty.a ']'
+ '[' -f /usr/lib64/libiberty.a ']'
+ export LIBIBERTYLIBDIR=/usr/lib64/libiberty.a
+ LIBIBERTYLIBDIR=/usr/lib64/libiberty.a
+ cd 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2

+ rm -rf dyninst-8.2
+ /usr/bin/gzip -dc 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.tar.gz

+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd dyninst-8.2
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch (dyninst-8.2.patch):'
Patch (dyninst-8.2.patch):
+ /bin/cat 
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.patch

+ /usr/bin/patch -p1 --fuzz=0
(Stripping trailing CRs from patch.)
patching file CMakeLists.txt
+ pwd
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2
+ export 
DYNINST_ROOT=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2
+ 
DYNINST_ROOT=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2

+ '[' bgqfe == bgp ']'
+ '[' bgqfe == bgq ']'
+ cmake . 
-DCMAKE_INSTALL_PREFIX=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 
-DINSTALL_LIB_DIR=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64 
-DINSTALL_INCLUDE_DIR=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/include/dyninst 
-DCMAKE_PREFIX_PATH=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 

Re: [DynInst_API:] Building DyninstAPI on BG/Q

[Jim Galarowicz]

Hi Bill,

Ok.  I fell back to 8.1.2 and it built on the BG/Q FE.

Thanks,
Jim G

On 03/24/2014 09:03 AM, Bill Williams wrote:

Jim--

I'm going to be poking at a bare Dyninst build on useq today, as it 
happens. I'll let you know what I find out.


--bw

On 03/24/2014 09:47 AM, Jim Galarowicz wrote:

Hi all,

I'm trying to build DyninstAPI on the FE of a BG/Q.   I'm getting an
assembly error.
Can anyone see if I'm doing something wrong or if there is a build issue
in Dyninst?

Thanks,
Jim G


+ exit 0
VAMPIRTRACE BUILT SUCCESSFULLY.
Build dyninst? y/n


Build-RPM command-line argument #1 = dyninst-8.2
Build-RPM command-line argument #2 =
Build-RPM command-line argument #3 =

DEBUG: Setting machine to OPENSS_TARGET_ARCH: rzuseqlac2
RPM working directory: rzuseqlac2
Environment variable KRELL_ROOT_PREFIX is set
Environment variable KRELL_ROOT_PREFIX is set to
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3
Executing(%prep): /bin/sh -e
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/INSTALL/rzuseqlac2/rpm-tmp.UiXNdk 



+ umask 022
+ cd
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2 


+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' -d dyninst-8.2 ']'
+ rm -fr dyninst-8.2
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -d
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/include -a -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/include/boost/shared_ptr.hpp 


']'
+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/boost/shared_ptr.hpp 


']'
+ export DYNINST_BOOST_ROOT=
+ DYNINST_BOOST_ROOT=
+ '[' '!' -z ']'
+ '[' '!' -z ']'
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 
']'

+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.so
-o -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.a 
']'
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 
']'

+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3//libelf.so -o
-f /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3//libelf.a 
']'

+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.so
-o -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libelf.a 
']'

+ export LIBELFDIR=/usr
+ LIBELFDIR=/usr
+ '[' -f /usr/include/libelf.h ']'
+ export LIBELFINC=/usr/include
+ LIBELFINC=/usr/include
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 
']'

+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libdwarf.so 


-o -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libdwarf.a 
']'


+ export
LIBDWARFDIR=/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3
+ LIBDWARFDIR=/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3
+ '[' '!' -z ']'
+ '[' '!' -z /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 
']'

+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libiberty.a 


']'
+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64/libiberty.a 


']'
+ '[' -d /usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 ']'
+ '[' -f
/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib/libiberty.a
']'
+ '[' -f /usr/lib/libiberty.a ']'
+ '[' -f /usr/lib64/libiberty.a ']'
+ export LIBIBERTYLIBDIR=/usr/lib64/libiberty.a
+ LIBIBERTYLIBDIR=/usr/lib64/libiberty.a
+ cd
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2 


+ rm -rf dyninst-8.2
+ /usr/bin/gzip -dc
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.tar.gz 



+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd dyninst-8.2
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch (dyninst-8.2.patch):'
Patch (dyninst-8.2.patch):
+ /bin/cat
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/SOURCES/dyninst-8.2.patch 



+ /usr/bin/patch -p1 --fuzz=0
(Stripping trailing CRs from patch.)
patching file CMakeLists.txt
+ pwd
/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2 



+ export
DYNINST_ROOT=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2 



+
DYNINST_ROOT=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILD/rzuseqlac2/dyninst-8.2 



+ '[' bgqfe == bgp ']'
+ '[' bgqfe == bgq ']'
+ cmake .
-DCMAKE_INSTALL_PREFIX=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3 

-DINSTALL_LIB_DIR=/usr/global/tools/openspeedshop/oss-dev/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.ppc64/usr/global/tools/openspeedshop/oss-dev/krellroot_v2.1u3/lib64 

-DINSTALL_INCLUDE_DIR=/usr/global/tools

Re: [DynInst_API:] libcommon.so - undefined reference to `cplus_demangle'

[Jim Galarowicz]

Thanks Bill and Josh, all,

I just rebuilt and with your suggestions, it is working.

[jeg@jeghost lib64]$ nm libcommon.so | grep mangle
0006e7b0 T ada_demangle
0006ed80 T cplus_demangle
...
...


Thanks,
Jim G

On 03/11/2014 12:18 PM, Josh Stone wrote:

On 03/11/2014 12:03 PM, Jim Galarowicz wrote:

Hi Bill,

In response to your email (thanks Josh and Matt), I think I'm passing in
the correct parameters.
Unless I'm supposed to pass something different than this, below:
   CMakeCache.txt:IBERTY_LIBRARY:FILEPATH=/usr/lib64

You need the whole file path, not just the directory, e.g.
-DIBERTY_LIBRARY=/usr/lib64/libiberty.a

This works for me, but I intend to make the auto-detection work too.


I've also attached some of the files from the top level directory.

I'm still seeing an undefined in libcommon.so for cplus_demangle.

[jeg@jeghost lib64]$ nm libcommon.so.8.2.0 | grep mangle
   U cplus_demangle
0002af80 t _Z10dedemanglePcS_
00063b30 T _Z16P_cplus_demanglePKcbb


build.txt is the screen output from the build that has this cmake line:
+ cmake .
-DCMAKE_INSTALL_PREFIX=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3
-DINSTALL_LIB_DIR=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3/lib64
-DINSTALL_INCLUDE_DIR=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3/include/dyninst
-DCMAKE_PREFIX_PATH=/home/jeg/OpenSpeedShop_ROOT/BUILDROOT/dyninst-8.2-1.x86_64/opt/krellroot_v2.1u3
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DLIBDWARF_LIBRARIES=/opt/krellroot_v2.1u3/lib64
-DLIBDWARF_INCLUDE_DIR=/opt/krellroot_v2.1u3/include
-DLIBELF_LIBRARIES=/usr/lib64 -DLIBELF_INCLUDE_DIR=/usr/include
-DPATH_BOOST= -DIBERTY_LIBRARY=/usr/lib64


Thanks,
Jim G

On 03/11/2014 11:51 AM, Josh Stone wrote:

On 03/11/2014 09:18 AM, Matthew LeGendre wrote:

On Tue, 11 Mar 2014, Josh Stone wrote:

For the other option Bill mentioned, set cmake -DUSE_GNU_DEMANGLER=1,
which makes it use abi::__cxa_demangle from libstdc++ instead of
cplus_demangle from libiberty.  I'm not sure of pros/cons either way.

The major con to using g++'s built-in demangler is that it can't
handle binaries produced by the Portland Group Compiler.

OK, I see.  FWIW, binutils and libstdc++ have identical libiberty/
source directories, so all the demangling code is shared.  But only
cplus_demangle has the extra options parameter, which Dyninst uses to
set DMGL_ARM for pgCC.

I wasn't going to bother with libiberty, since we obviously have
libstdc++ already, but this option control seems reason enough.
However, the build doesn't recognize that Fedora/RHEL libiberty.a is
PIC, so it falls back to the download method.  I'll see if that can be
fixed up...

Josh



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

[DynInst_API:] libcommon.so - undefined reference to `cplus_demangle'

[Jim Galarowicz]

Hi Dyninst team,

I'm looking for some advice on how to resolve, in a reasonable fashion a 
linking error I'm seeing.


I'm trying to link the OpenSpeedShop utility: osswrapper using the new 
8.2 git tree dyninst but I'm getting an undefined from libcommon for 
cplus_demangle.


I'm seeing the issue on Fedora 20.  I did not have trouble linking on 
Fedora 19 after I added an extra dyninst libs variable to our 
ax_dyninst.m4 file and used that in the linking of osswrapper.


   DYNINST_EXTRA_LIBS=$BINUTILS_IBERTY_LIB $LIBELF_LIBS $LIBDWARF_LIBS 
   DYNINST_EXTRA_LDFLAGS=$BINUTILS_IBERTY_LDFLAGS $LIBELF_LDFLAGS
   $LIBDWARF_LDFLAGS

I then added the @DYNINST_EXTRA_LIBS@ and @DYNINST_EXTRA_LDFLAGS@ into 
my Makefile.am file where I'm linking osswrapper.
I already had LIBELF_LDFLAGS, LIBELF_LIBS and 
LIBDWARF_LDFLAGS/LIBDWARF_LIBS in the Makefile because they are required 
by the dyninst libraries too.  So, I combined them all into the extra 
libs/ldflags variables.


However, that doesn't seem to work on Fedora 20, where there must be a 
different linking order in place?


Anyway, that triggered a bigger question about linking in needed 
libraries when using dyninst.
If libiberty is an archive as it seems to be on the Fedora systems I 
have access to, shouldn't that just be linked into libcommon.so by the 
dyninst build?


I can get it to link on Fedora 20 but I had to add the libiberty path 
and library name into the dyininst lib list in our m4/ax_dyninst.m4 
file.   Seems kind-of hokey to me, so I'm asking for advice on this.


DYNINST_LIBS=-ldyninstAPI -lcommon $BINUTILS_IBERTY_LDFLAGS 
$BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI -lpatchAPI 
-lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite


Here is the original link issue: (where -liberty is present, but not 
right after libcommon).


libtool: link: g++ -DLIBDIR=\/opt/cbtf_only_v1.1u1/lib64\ 
-DXMLDIR=\/opt/cbtf_only_v1.1u1/share/KrellInstitute/xml\ -I../include 
-pthread -I/opt/cbtf_only_v1.1u1/include -I/opt/cbtf_only_v1.1u1/include 
-I/opt/cbtf_only_v1.1u1/include -I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/include/dyninst -DUSE_STL_VECTOR -std=c++0x 
-I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/lib64/mrnet-4.0.0/include 
-I/opt/krellroot_v2.1u3/lib64/xplat-4.0.0/include -Dos_linux -g -O2 
-DLIB_DIR=lib64 -o .libs/collectionTool collectionTool-collectionTool.o 
-Wl,--whole-archive -Wl,--no-whole-archive  -L../src 
-L/opt/cbtf_only_v1.1u1/lib64 -L/opt/krellroot_v2.1u3/lib64 
-lboost_program_options -lboost_filesystem -lboost_system -lboost_thread 
-lcbtf -lcbtf-mrnet -lcbtf-xml -liberty -lelf -lxerces-c 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-symtabapi.so 
-ldwarf -lcommon -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf 
-ldynDwarf -lsymLite 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-mrnet.so 
-lmrnet -lxplat -lpthread 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core.so 
/opt/cbtf_only_v1.1u1/lib64/libcbtf-messages-perfdata.so -lltdl -ldl 
-pthread -Wl,-rpath -Wl,/opt/cbtf_only_v1.1u1/lib64
/opt/krellroot_v2.1u3/lib64/libcommon.so: undefined reference to 
`cplus_demangle'

collect2: error: ld returned 1 exit status
make: *** [collectionTool] Error 1


[dew@localhost collectionTool]$ ldd /opt/krellroot_v2.1u3/lib64/libcommon.so
linux-vdso.so.1 =  (0x7fff083fe000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x7fc6ae3d8000)
libm.so.6 = /usr/lib64/libm.so.6 (0x7fc6ae0d)
libgcc_s.so.1 = /usr/lib64/libgcc_s.so.1 (0x7fc6adeba000)
libc.so.6 = /usr/lib64/libc.so.6 (0x7fc6adafb000)
/lib64/ld-linux-x86-64.so.2 (0x003434e0)

[dew@localhost collectionTool]$ nm 
/opt/krellroot_v2.1u3/lib64/libcommon.so | grep  U 

 U abort@@GLIBC_2.2.5
 U __assert_fail@@GLIBC_2.2.5
 U calloc@@GLIBC_2.2.5
 U ceilf@@GLIBC_2.2.5
 U closedir@@GLIBC_2.2.5
 U close@@GLIBC_2.2.5
 U cplus_demangle
 U ctime@@GLIBC_2.2.5
 U __cxa_atexit@@GLIBC_2.2.5
 U __cxa_begin_catch@@CXXABI_1.3
 U __cxa_end_catch@@CXXABI_1.3
 U __cxa_guard_abort@@CXXABI_1.3
 U __cxa_guard_acquire@@CXXABI_1.3
 U __cxa_guard_release@@CXXABI_1.3

[dew@localhost collectionTool]$ lsr /usr/lib64/libiber*
460 -rw-r--r--. 1 root root 469744 Aug 30  2013 /usr/lib64/libiberty.a
[dew@localhost collectionTool]$


[dew@localhost m4]$ diff ax_dyninst.m4-seemedToWork ax_dyninst.m4
Key for diffs
 works
 does not

107,110c107,110
 DYNINST_LIBS=-ldyninstAPI -lcommon 
$BINUTILS_IBERTY_LDFLAGS $BINUTILS_IBERTY_LIB -lsymtabAPI 
-linstructionAPI -lparseAPI -lpatchAPI -lstackwalk -lpcontrol -ldynElf 
-ldynDwarf -lsymLite

  

Re: [DynInst_API:] libcommon.so - undefined reference to `cplus_demangle'

[Jim Galarowicz]

Hi Dyninst team,

I was wrong about it working on Fedora 19.  It fails there in the same 
way as on Fedora 20.  I need to beef up the build failure detection.


Thanks,
Jim G

On 03/10/2014 08:36 PM, Jim Galarowicz wrote:

Hi Dyninst team,

I'm looking for some advice on how to resolve, in a reasonable fashion 
a linking error I'm seeing.


I'm trying to link the OpenSpeedShop utility: osswrapper using the new 
8.2 git tree dyninst but I'm getting an undefined from libcommon for 
cplus_demangle.


I'm seeing the issue on Fedora 20.  I did not have trouble linking on 
Fedora 19 after I added an extra dyninst libs variable to our 
ax_dyninst.m4 file and used that in the linking of osswrapper.


DYNINST_EXTRA_LIBS=$BINUTILS_IBERTY_LIB $LIBELF_LIBS $LIBDWARF_LIBS 
DYNINST_EXTRA_LDFLAGS=$BINUTILS_IBERTY_LDFLAGS $LIBELF_LDFLAGS
$LIBDWARF_LDFLAGS

I then added the @DYNINST_EXTRA_LIBS@ and @DYNINST_EXTRA_LDFLAGS@ into 
my Makefile.am file where I'm linking osswrapper.
I already had LIBELF_LDFLAGS, LIBELF_LIBS and 
LIBDWARF_LDFLAGS/LIBDWARF_LIBS in the Makefile because they are 
required by the dyninst libraries too.  So, I combined them all into 
the extra libs/ldflags variables.


However, that doesn't seem to work on Fedora 20, where there must be a 
different linking order in place?


Anyway, that triggered a bigger question about linking in needed 
libraries when using dyninst.
If libiberty is an archive as it seems to be on the Fedora systems I 
have access to, shouldn't that just be linked into libcommon.so by the 
dyninst build?


I can get it to link on Fedora 20 but I had to add the libiberty path 
and library name into the dyininst lib list in our m4/ax_dyninst.m4 
file.   Seems kind-of hokey to me, so I'm asking for advice on this.


DYNINST_LIBS=-ldyninstAPI -lcommon $BINUTILS_IBERTY_LDFLAGS 
$BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI 
-lpatchAPI -lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite


Here is the original link issue: (where -liberty is present, but not 
right after libcommon).


libtool: link: g++ -DLIBDIR=\/opt/cbtf_only_v1.1u1/lib64\ 
-DXMLDIR=\/opt/cbtf_only_v1.1u1/share/KrellInstitute/xml\ 
-I../include -pthread -I/opt/cbtf_only_v1.1u1/include 
-I/opt/cbtf_only_v1.1u1/include -I/opt/cbtf_only_v1.1u1/include 
-I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/include/dyninst -DUSE_STL_VECTOR -std=c++0x 
-I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/lib64/mrnet-4.0.0/include 
-I/opt/krellroot_v2.1u3/lib64/xplat-4.0.0/include -Dos_linux -g -O2 
-DLIB_DIR=lib64 -o .libs/collectionTool 
collectionTool-collectionTool.o -Wl,--whole-archive 
-Wl,--no-whole-archive  -L../src -L/opt/cbtf_only_v1.1u1/lib64 
-L/opt/krellroot_v2.1u3/lib64 -lboost_program_options 
-lboost_filesystem -lboost_system -lboost_thread -lcbtf -lcbtf-mrnet 
-lcbtf-xml -liberty -lelf -lxerces-c 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-symtabapi.so 
-ldwarf -lcommon -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf 
-ldynDwarf -lsymLite 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-mrnet.so 
-lmrnet -lxplat -lpthread 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core.so 
/opt/cbtf_only_v1.1u1/lib64/libcbtf-messages-perfdata.so -lltdl -ldl 
-pthread -Wl,-rpath -Wl,/opt/cbtf_only_v1.1u1/lib64
/opt/krellroot_v2.1u3/lib64/libcommon.so: undefined reference to 
`cplus_demangle'

collect2: error: ld returned 1 exit status
make: *** [collectionTool] Error 1


[dew@localhost collectionTool]$ ldd 
/opt/krellroot_v2.1u3/lib64/libcommon.so

linux-vdso.so.1 =  (0x7fff083fe000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x7fc6ae3d8000)
libm.so.6 = /usr/lib64/libm.so.6 (0x7fc6ae0d)
libgcc_s.so.1 = /usr/lib64/libgcc_s.so.1 (0x7fc6adeba000)
libc.so.6 = /usr/lib64/libc.so.6 (0x7fc6adafb000)
/lib64/ld-linux-x86-64.so.2 (0x003434e0)

[dew@localhost collectionTool]$ nm 
/opt/krellroot_v2.1u3/lib64/libcommon.so | grep  U 

 U abort@@GLIBC_2.2.5
 U __assert_fail@@GLIBC_2.2.5
 U calloc@@GLIBC_2.2.5
 U ceilf@@GLIBC_2.2.5
 U closedir@@GLIBC_2.2.5
 U close@@GLIBC_2.2.5
 U cplus_demangle
 U ctime@@GLIBC_2.2.5
 U __cxa_atexit@@GLIBC_2.2.5
 U __cxa_begin_catch@@CXXABI_1.3
 U __cxa_end_catch@@CXXABI_1.3
 U __cxa_guard_abort@@CXXABI_1.3
 U __cxa_guard_acquire@@CXXABI_1.3
 U __cxa_guard_release@@CXXABI_1.3

[dew@localhost collectionTool]$ lsr /usr/lib64/libiber*
460 -rw-r--r--. 1 root root 469744 Aug 30  2013 /usr/lib64/libiberty.a
[dew@localhost collectionTool]$


[dew@localhost m4]$ diff ax_dyninst.m4-seemedToWork ax_dyninst.m4
Key for diffs
 works

Re: [DynInst_API:] libcommon.so - undefined reference to `cplus_demangle'

[Jim Galarowicz]

Hi again,

A little more information.
I guess we didn't see this issue with the previous version of dyninst 
because libcommon.so did contain libiberty.a


[jeg@jeghost lib64]$ nm libcommon.so.8.1.2 | grep cplus_demangle
00077b90 T cplus_demangle
0029ee60 D cplus_demangle_builtin_types
00082a50 T cplus_demangle_fill_ctor
00082a80 T cplus_demangle_fill_dtor
00082a10 T cplus_demangle_fill_extended_operator
000828b0 T cplus_demangle_fill_name

[jeg@jeghost lib64]$ nm libcommon.so.8.2.0 | grep cplus_demangle
 U cplus_demangle
00063b30 T _Z16P_cplus_demanglePKcbb
00071260 r _ZZ16P_cplus_demanglePKcbbE19__PRETTY_FUNCTION__

Thanks,
Jim G


On 03/10/2014 09:18 PM, Jim Galarowicz wrote:


Hi Dyninst team,

I was wrong about it working on Fedora 19.  It fails there in the same 
way as on Fedora 20.  I need to beef up the build failure detection.


Thanks,
Jim G

On 03/10/2014 08:36 PM, Jim Galarowicz wrote:

Hi Dyninst team,

I'm looking for some advice on how to resolve, in a reasonable 
fashion a linking error I'm seeing.


I'm trying to link the OpenSpeedShop utility: osswrapper using the 
new 8.2 git tree dyninst but I'm getting an undefined from libcommon 
for cplus_demangle.


I'm seeing the issue on Fedora 20.  I did not have trouble linking on 
Fedora 19 after I added an extra dyninst libs variable to our 
ax_dyninst.m4 file and used that in the linking of osswrapper.


DYNINST_EXTRA_LIBS=$BINUTILS_IBERTY_LIB $LIBELF_LIBS
$LIBDWARF_LIBS 
DYNINST_EXTRA_LDFLAGS=$BINUTILS_IBERTY_LDFLAGS $LIBELF_LDFLAGS
$LIBDWARF_LDFLAGS

I then added the @DYNINST_EXTRA_LIBS@ and @DYNINST_EXTRA_LDFLAGS@ 
into my Makefile.am file where I'm linking osswrapper.
I already had LIBELF_LDFLAGS, LIBELF_LIBS and 
LIBDWARF_LDFLAGS/LIBDWARF_LIBS in the Makefile because they are 
required by the dyninst libraries too.  So, I combined them all into 
the extra libs/ldflags variables.


However, that doesn't seem to work on Fedora 20, where there must be 
a different linking order in place?


Anyway, that triggered a bigger question about linking in needed 
libraries when using dyninst.
If libiberty is an archive as it seems to be on the Fedora systems I 
have access to, shouldn't that just be linked into libcommon.so by 
the dyninst build?


I can get it to link on Fedora 20 but I had to add the libiberty path 
and library name into the dyininst lib list in our m4/ax_dyninst.m4 
file.   Seems kind-of hokey to me, so I'm asking for advice on this.


DYNINST_LIBS=-ldyninstAPI -lcommon $BINUTILS_IBERTY_LDFLAGS 
$BINUTILS_IBERTY_LIB -lsymtabAPI -linstructionAPI -lparseAPI 
-lpatchAPI -lstackwalk -lpcontrol -ldynElf -ldynDwarf -lsymLite


Here is the original link issue: (where -liberty is present, but not 
right after libcommon).


libtool: link: g++ -DLIBDIR=\/opt/cbtf_only_v1.1u1/lib64\ 
-DXMLDIR=\/opt/cbtf_only_v1.1u1/share/KrellInstitute/xml\ 
-I../include -pthread -I/opt/cbtf_only_v1.1u1/include 
-I/opt/cbtf_only_v1.1u1/include -I/opt/cbtf_only_v1.1u1/include 
-I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/include/dyninst -DUSE_STL_VECTOR -std=c++0x 
-I/opt/krellroot_v2.1u3/include -I/opt/krellroot_v2.1u3/include 
-I/opt/krellroot_v2.1u3/lib64/mrnet-4.0.0/include 
-I/opt/krellroot_v2.1u3/lib64/xplat-4.0.0/include -Dos_linux -g -O2 
-DLIB_DIR=lib64 -o .libs/collectionTool 
collectionTool-collectionTool.o -Wl,--whole-archive 
-Wl,--no-whole-archive  -L../src -L/opt/cbtf_only_v1.1u1/lib64 
-L/opt/krellroot_v2.1u3/lib64 -lboost_program_options 
-lboost_filesystem -lboost_system -lboost_thread -lcbtf -lcbtf-mrnet 
-lcbtf-xml -liberty -lelf -lxerces-c 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-symtabapi.so 
-ldwarf -lcommon -lsymtabAPI -linstructionAPI -lparseAPI -ldynElf 
-ldynDwarf -lsymLite 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core-mrnet.so 
-lmrnet -lxplat -lpthread 
/home/dew/OpenSpeedShop_ROOT/BUILD/localhost.localdomain/cbtf-krell/core/src/.libs/libcbtf-core.so 
/opt/cbtf_only_v1.1u1/lib64/libcbtf-messages-perfdata.so -lltdl -ldl 
-pthread -Wl,-rpath -Wl,/opt/cbtf_only_v1.1u1/lib64
/opt/krellroot_v2.1u3/lib64/libcommon.so: undefined reference to 
`cplus_demangle'

collect2: error: ld returned 1 exit status
make: *** [collectionTool] Error 1


[dew@localhost collectionTool]$ ldd 
/opt/krellroot_v2.1u3/lib64/libcommon.so

linux-vdso.so.1 =  (0x7fff083fe000)
libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x7fc6ae3d8000)
libm.so.6 = /usr/lib64/libm.so.6 (0x7fc6ae0d)
libgcc_s.so.1 = /usr/lib64/libgcc_s.so.1 (0x7fc6adeba000)
libc.so.6 = /usr/lib64/libc.so.6 (0x7fc6adafb000)
/lib64/ld-linux-x86-64.so.2 (0x003434e0)

[dew@localhost collectionTool]$ nm 
/opt/krellroot_v2.1u3/lib64/libcommon.so | grep  U 

 U abort@@GLIBC_2.2.5
 U __assert_fail

Re: [DynInst_API:] Dyninst 8.2(top of git) build issues

[Jim Galarowicz]

Hi Josh,

Thanks for the reply and suggestions!

I will actually try the rpm on F20, because that is a lot easier, but we 
also want to build Dyninst ourselves for our development on platforms 
where the rpms are not available, so we try to keep up with the Dyninst 
development stages.


Thanks for your help!   Matt sent me a patch that I'm trying now.

Jim G


On 03/07/2014 09:07 AM, Josh Stone wrote:

On 03/07/2014 07:48 AM, Jim Galarowicz wrote:

Hi Dyninst team,

When I tried to build the existing 8.1.2 version on Fedora 20 with
gcc-4.8.2 I encountered some compile errors in proccontrol,

For dyninst-8.1.2, note that F20 does have packages already.  If you
still want to compile your own, you can use the same patch we have to
fix the ptrace conflict:

http://pkgs.fedoraproject.org/cgit/dyninst.git/plain/dyninst-pokeuser.patch

This fix has been included in dyninst.git master already.


so I downloaded yesterdays Dyninst git tree snapshot and tried to
build it using my spec file created to use the new cmake style
build.

I had also experimented with a dyninst rpm in the new cmake build, and
had no issues, but this was a while ago.  See below...


We (OSS team) have always set the libdir to lib64 on x86_64 machines and
installed the dyninst includes into install_dir/include/dyninst.
When I use this cmake command (on Fedora 20 using gcc-4.8.2), I get some
files that don't follow that lib64 and install_dir/include/dyninst
suggestions.

   cmake . -DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{prefix}
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT%{prefix}/lib64
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT%{prefix}/include/dyninst
-DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT%{prefix}
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DLIBDWARF_LIBRARIES=$LIBDWARFDIR/%{libdir}
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFDIR/include
-DLIBELF_LIBRARIES=$LIBELFDIR/%{libdir} -DLIBELF_INCLUDE_DIR=$LIBELFINC
-DPATH_BOOST=$DYNINST_BOOST_ROOT -DLIBIBERTY_LIBRARY=$LIBIBERTYLIBDIR
-DIBERTY_LIBRARY=$LIBIBERTYLIBDIR

These files are flagged by rpm as installed but not packaged because we
are expecting them to be in the specified directory paths.
Can you see/tell if I am doing something wrong in the cmake command, or
is this a dyninst build/configure issue?

/opt/krellroot/include/dyninstAPI_RT.h
/opt/krellroot/include/dyninstRTExport.h
/opt/krellroot/lib/libdyninstAPI_RT.a
/opt/krellroot/lib/libdyninstAPI_RT.so
/opt/krellroot/lib/libdyninstAPI_RT.so.8.2
/opt/krellroot/lib/libdyninstAPI_RT.so.8.2.0

Since these are exactly just the RT files, this reminded me that Matt
split dyninstAPI_RT into a cmake subproject a few months ago, in commit
fef984b105cc.  I guess it is not passing all of the -D options through,
and we should fix this.

Alternatively, at least as a stopgap, you can probably invoke cmake
manually on dyninstAPI_RT/ with all your options, to overwrite the
nested invocation from the top level.


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


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

Re: [DynInst_API:] Dyninst 8.2(top of git) build issues

[Jim Galarowicz]

Hi Matt,

Your patch fixes the build issue I was seeing!

Thanks!

Jim G

On 03/07/2014 10:30 AM, Matthew LeGendre wrote:


On Fri, 7 Mar 2014, Josh Stone wrote:

On 03/07/2014 07:48 AM, Jim Galarowicz wrote:
We (OSS team) have always set the libdir to lib64 on x86_64 machines 
and

installed the dyninst includes into install_dir/include/dyninst.
When I use this cmake command (on Fedora 20 using gcc-4.8.2), I get 
some

files that don't follow that lib64 and install_dir/include/dyninst
suggestions.

  cmake . -DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{prefix}
-DINSTALL_LIB_DIR=$RPM_BUILD_ROOT%{prefix}/lib64
-DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT%{prefix}/include/dyninst
-DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT%{prefix}
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DLIBDWARF_LIBRARIES=$LIBDWARFDIR/%{libdir}
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFDIR/include
-DLIBELF_LIBRARIES=$LIBELFDIR/%{libdir} -DLIBELF_INCLUDE_DIR=$LIBELFINC
-DPATH_BOOST=$DYNINST_BOOST_ROOT -DLIBIBERTY_LIBRARY=$LIBIBERTYLIBDIR
-DIBERTY_LIBRARY=$LIBIBERTYLIBDIR

These files are flagged by rpm as installed but not packaged because we
are expecting them to be in the specified directory paths.
Can you see/tell if I am doing something wrong in the cmake command, or
is this a dyninst build/configure issue?

   /opt/krellroot/include/dyninstAPI_RT.h
   /opt/krellroot/include/dyninstRTExport.h
   /opt/krellroot/lib/libdyninstAPI_RT.a
   /opt/krellroot/lib/libdyninstAPI_RT.so
   /opt/krellroot/lib/libdyninstAPI_RT.so.8.2
   /opt/krellroot/lib/libdyninstAPI_RT.so.8.2.0

Since these are exactly just the RT files, this reminded me that Matt
split dyninstAPI_RT into a cmake subproject a few months ago, in commit
fef984b105cc.  I guess it is not passing all of the -D options through,
and we should fix this.


Josh is correct.  The RT library was split into a seperate CMake 
project as part of BlueGene/Q support.  We manually invoke that 
project from the top-level CMake with what we think are the necessary 
options.


Except we're not passing some of the options you're using, such as the 
explicit LIB and INCLUDE install locations.  I should just have to add 
those to the list of options passed to the RT library.



Alternatively, at least as a stopgap, you can probably invoke cmake
manually on dyninstAPI_RT/ with all your options, to overwrite the
nested invocation from the top level.


That would work.

But the fix should just involve modifying a single line (knock on 
wood). How about I'll send you a patch, and if that works it can get 
pushed to master.


-Matt


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