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.
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
--
Konstantelias Ioannis
Undergraduate at
Department of Electrical and Computer Engineering
University of Thessaly, Greece
Attachment:
find_func.tar.gz
Description: application/gzip
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}