You might be hitting a common problem that manifests when a system has
installs of both the orignal libelf (libelf.so.0) and the RedHat version
of libelf (libelf.so.1). If Dyninst is built against the header files of
one libelf and the library of the other, that can cause it to fail to
parse symbols.
-Matt
On Tue, 28 Jul 2015, Bill Williams wrote:
On 07/27/2015 05:50 PM, Ioannis Konstadelias wrote:
Well,
maybe then I have something wrong in my mutator source. Here is the
whole directory. I use the version with the commit that fixes the boost
problem.
Your mutator also works fine for me locally, and the not-yet-committed
changes I have are quite small and not relevant to this issue. I do have
Xiaozhu's parsing fixes, which you may or may not have pulled. If you
have pulled them, there's probably something not quite clean in your
Dyninst build.
On 27/07/2015 11:05 ÎÎ, Bill Williams wrote:
With this mutatee and git-head locally, the following sequence:
BPatch bp;
BPatch_binaryEdit* be = bp.openBinary(argv[1]);
std::vector<BPatch_function*> bpfuncs;
be->getImage()->findFunction("foo", bpfuncs);
cerr << "Found " << bpfuncs.size() << " funcs" << endl;
is finding one function "foo" for me, as expected.
On 07/27/2015 11:57 AM, Ioannis Konstadelias wrote:
Here it is.
On 27/07/2015 07:53 ÎÎ, Bill Williams wrote:
On 07/27/2015 11:41 AM, Ioannis Konstadelias wrote:
Sorry,
My bad. I should've tell you. I've also tried
includeUninstrumentable =
true but the results were the same.
That seems fishy. Mind sending me the mutatee binary?
On 27/07/2015 07:01 ÎÎ, Bill Williams wrote:
On 07/25/2015 11:44 AM, Ioannis Konstadelias wrote:
Hi everyone,
first of all I use the latest version of dyninstAPI (git head).
I was experimenting with the mutator program of the Appendix A from
the
manuals (not the re-tee one),
and tried the custom really simple mutatee program below:
#include <stdio.h>
int foo() {return 1;}
int main(void)
{
puts("Hello, world!");
foo();
return 0;
}
I added the counter snippet for main and it worked. But never
worked for
function foo. The error I took was:
Reading symbols from ./func_instr...done.
(gdb) run
Starting program: /home/gon1332/Training/Dyninst/func_instr
Traceback (most recent call last):
File
"/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py",
line 63, in <module>
from libstdcxx.v6.printers import
register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff46af700 (LWP 23032)]
[New Thread 0x7ffff3eae700 (LWP 23033)]
[New Thread 0x7ffff34a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x00000000004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50 points = functions[0]->findPoint(BPatch_entry);
(gdb) q
A debugging session is active.
Inferior 1 [process 23027] will be killed.
I tried nm and the foo function was there mangled:
â Dyninst nm hello | grep foo
000000000040057d T _Z3foov
but according to your note about findFunction:
/*"*[NOTE: If name is not found to match any demangled function
names in the module, the search is repeated as if name is a
mangled
function name. If this second search succeeds, functions with
mangled names matching name are returned instead.]*"*/
shouldn't it be working?
It should, but very small functions are not always marked as
instrumentable (which in practice means instrumentable without using
traps). Try findFunction with includeUninstrumentable = true, and let
me know if that works.
Should I demangle (or mangle) it by myshelf and then search?
Thanks,
Ioannis Konstantelias,
Undergraduate at University of Thessaly
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}