Re: [DynInst_API:] libsymtabAPI has undefined reference dwarf_next_lines@ELFUTILS_0.173

[Sasha Da Rocha Pinheiro]

Yes, you're correct: the latest. And it looks like they;ve updated it already. 
So it's fine.


From: Dyninst-api  on behalf of Saija Sorsa 

Sent: Monday, September 17, 2018 8:23:37 AM
To: John Mellor-Crummey
Cc: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] libsymtabAPI has undefined reference 
dwarf_next_lines@ELFUTILS_0.173


Hi,



Afaik it actually downloads the latest which is .174 
(https://sourceware.org/elfutils/ftp/). I’m still in the middle of getting the 
version right. Thank you for your help.



From: John Mellor-Crummey 
Sent: 14 September 2018 17:50
To: Saija Sorsa 
Cc: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] libsymtabAPI has undefined reference 
dwarf_next_lines@ELFUTILS_0.173



You need to download and use the latest elfutils 0.173, which provides this 
function.



This may have been handled automatically in the build configuration if you 
reconfigure with cmake, but I am not sure about that.

--

John Mellor-Crummey



(sent from my phone)

On Sep 14, 2018, at 5:01 AM, Saija Sorsa 
mailto:sso...@nvidia.com>> wrote:

Hi,



I’m new to dyninst, this is the first time I’m using it, please excuse my 
ignorance. I’m having 14.04.1-Ubuntu and I git pulled dyninst and compiled it 
(cmake & cmake install). I have a code that is using dyninstAPI, mostly 
BPatch*. While executing make for the code I get this error:

//usr/local/lib/libsymtabAPI.so.9.3: undefined reference to 
`dwarf_next_lines@ELFUTILS_0.173'



Are you able to help me with this? It smells like a version mismatch / changed 
API in dyninst. Latest git commit for my code is around 6months ago, but the 
dyninst part is even older, if I’m correct. Any debugging suggestions?



Thanks!





This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.



___
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:] Compile errors in Object-elf.C with latest source\ttop of tree

[Sasha Da Rocha Pinheiro]

Emplace functions for multi_index_container were added to boost in the 1.55 
release. You might be using an older version.


Get Outlook for Android


From: Dyninst-api  on behalf of Jim Galarowicz 

Sent: Saturday, September 15, 2018 11:24:16 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] Compile errors in Object-elf.C with latest source top 
of tree

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_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:4542:22:
error: ‘class
boost::multi_index::multi_index_container,

Re: [DynInst_API:] libsymtabAPI has undefined reference dwarf_next_lines@ELFUTILS_0.173

[Sasha Da Rocha Pinheiro]

Hi Saija,

You should `make clean && make install` to fix it.

Dyninst should download the correct version of Elfutil. Make sure you didn't 
set a path in the cmake configuration for an old version of Elfutils in your 
system.


Sasha


From: Dyninst-api  on behalf of Saija Sorsa 

Sent: Friday, September 14, 2018 5:01:48 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] libsymtabAPI has undefined reference 
dwarf_next_lines@ELFUTILS_0.173


Hi,



I’m new to dyninst, this is the first time I’m using it, please excuse my 
ignorance. I’m having 14.04.1-Ubuntu and I git pulled dyninst and compiled it 
(cmake & cmake install). I have a code that is using dyninstAPI, mostly 
BPatch*. While executing make for the code I get this error:

//usr/local/lib/libsymtabAPI.so.9.3: undefined reference to 
`dwarf_next_lines@ELFUTILS_0.173'



Are you able to help me with this? It smells like a version mismatch / changed 
API in dyninst. Latest git commit for my code is around 6months ago, but the 
dyninst part is even older, if I’m correct. Any debugging suggestions?



Thanks!




This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

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

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

[Sasha Da Rocha Pinheiro]

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


Get Outlook for Android


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-Crummey Professor
Dept of Computer Science Rice University
email: 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
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:] libdwarf usage in Dyninst?

[Sasha Da Rocha Pinheiro]

Yes, that is true.

Get Outlook for Android


From: Dyninst-api  on behalf of Jim Galarowicz 

Sent: Wednesday, June 13, 2018 11:21:30 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] libdwarf usage in Dyninst?

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
___
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.

[Sasha Da Rocha Pinheiro]

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  on behalf of Xiaozhu Meng 

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 
> 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 

Re: [DynInst_API:] AARCH support?

[Sasha Da Rocha Pinheiro]

Hi Marc,
What do you get when you try to compile?

Sasha


Get Outlook for Android


From: Dyninst-api  on behalf of Barton Miller 

Sent: Wednesday, March 28, 2018 9:13:44 AM
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] AARCH support?


Hi Marc.

While the full port of Dyninst to ARM 64 (V8) is still underway, many of the 
Dyninst components work now on ARM.  These include the InstructionAPI, 
ParseAPI, ProcControlAPI, DataflowAPI and SymtabAPI (for reading/look-up 
functions ... rewriting functions are still to be done).

Give us a few more months to get it wrapped up.  In a development branch, we 
have code relocation working pretty well and the first of the Dyninst 
instrumentation tests are passing.

If anyone wants to contribute to the effort, please contact me.

BTW, our partner group at the Univ. of Maryland is busily working on an ARM 32 
port (the 32 and 64 bit instructions sets are quite different).

best,--bart

On 2018-03-28 3:51 AM, Marc wrote:

Hi guys,

is there a plan when AARCH support is being introduced?
I have seen a branch which has it but it does not compile for me.
And if there is need, I would offer to do testing on 32bit and 64bit aarch.

Regards,
Marc
___
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:] change in getFile from libdwarf to libdw

[Sasha Da Rocha Pinheiro]

Hi Mark,

I pushed a commit that fixed it, in the way that you suggested at:

(1) Declare the change as unintended and revert to the libdwarf
behavior by having Symtab prepend the comp dir so that getFile() and
getCallsite() return a full path.


It's already in master branch, commit e7b69e6c3eab49c002fe941e009bc9dc2da1042a.


Sasha


From: Mark W. Krentel <kren...@rice.edu>
Sent: Tuesday, March 20, 2018 11:26:33 PM
To: Sasha Da Rocha Pinheiro; dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] change in getFile from libdwarf to libdw

I wouldn't expect that a different elfutils would matter, but maybe.
I don't know.

I think the most likely difference is that maybe you're using a binary
that doesn't produce the difference (not built out-of-source), or else
you're not looking at all the examples.

For example, on my hpcstruct binary, I see some paths like:

/usr/include/c++/7/bits/basic_string.h
/usr/include/c++/7/bits/stl_tree.h
/home/krentel/Externals/BUILD/binutils/work/bfd/peigen.c

But I also see other paths like:

../../../../src/lib/banal/Struct.cpp
../../../../src/tool/hpcstruct/main.cpp
../../../../src/lib/support/CmdLineParser.cpp

It all depends on how you write the path on the compile line.

If you still don't see paths like this, then pick a machine at
Wisconsin where it's convenient for you to run this.  I have an
account on Bill's workstation (follis) but any machine where you can
loan me an account would do.  I can run through the steps my way and
your way and either show you a clear example, or else identify what
piece of the puzzle is the difference (probably).

And btw, I do suggest adding a method to return the value of
DW_AT_comp_dir per Module.  Something like Module::getCompDir() would
work.  It seems like a basic piece of information in the binary and I
don't see another straightforward way of accessing it through
SymtabAPI.

--Mark



On 03/20/18 19:23, Sasha Da Rocha Pinheiro wrote:

We are downloading and compiling elfutils with dyninst cmake. But my version is 
0.168.

I'll investigate this more.

What is follis? How do I access it?


What do you mean here?

And of course, some of the path names from /usr/include will
be full paths. But the relative paths from out-of-source builds
will not.

Sasha

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

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

[Sasha Da Rocha Pinheiro]

We are downloading and compiling elfutils with dyninst cmake. But my version is 
0.168.

I'll investigate this more.

What is follis? How do I access it?


What do you mean here?

And of course, some of the path names from /usr/include will
be full paths. But the relative paths from out-of-source builds
will not.

Sasha

From: Mark W. Krentel <kren...@rice.edu>
Sent: Tuesday, March 20, 2018 5:52:12 PM
To: Sasha Da Rocha Pinheiro; dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] change in getFile from libdwarf to libdw

I'm at Xiaozhu's commit b663cf98c97b6 from master as of yesterday,
March 19.  This includes the 84ffda2a8cc commit you mentioned.
I'm still seeing path names like ../../../../src/lib/analysis/Util.cpp.

Perhaps we're not using the same elfutils?  Mine is 0.170.

Make sure you're using a binary from an out-of-source build.  Any of
the x86 hpcstruct binaries from ~krentel/public/binaries on follis
should work.

And of course, some of the path names from /usr/include will
be full paths.  But the relative paths from out-of-source builds
will not.

--Mark




On 03/20/18 15:46, Sasha Da Rocha Pinheiro wrote:

Hi Mark,

I tested this myself. I am getting the full path with Statement getFile(), with 
libdw.


Bill told me he remembers doing some change that corrected it at some point.

I suspect it's the commit 84ffda2a8cca36b1c8f34c4eab9f1319989014ab.

But I'm not sure, this commit has a lot of changes.


What commit are you at that you're getting relative path?


Sasha

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

Re: [DynInst_API:] Read .debug_line section?

[Sasha Da Rocha Pinheiro]

Hi John,

After examining this, it looks like we get line info by compilation unit.

The info about the compilation units we get comes from an iteration using libdw 
dwarf_nextcu, which in turn depends on ".debug_info".

It seems that the whole abstraction of Module, DwarfWalker, Object, 
LineInformation and Symtab, relies on this way of getting line info.


This didn't change with the advent of libdw. The Dwarf_die was already being 
used this way.

I would need more time to have this abstraction more clear in order to plan on 
changing it, or making debug_line be used without debug_info.

Right now, I don't see a quick solution.


Sasha


From: Dyninst-api  on behalf of John 
Mellor-Crummey 
Sent: Monday, March 19, 2018 2:53:02 AM
To: dyninst-api
Subject: [DynInst_API:] Read .debug_line section?

I need to cope with CUDA binaries that contain a .debug_line section but don’t 
have a .debug_info section. I didn’t see any code in Dyninst to read line 
information from a .debug_line section. Did I miss something?
--
John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: joh...@rice.edu phone: 713-348-5179

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