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