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