Re: [DynInst_API:] Cannot find function
I indeed have both installs of libelf.so.{0,1}. But I have only one
libelf.h and it is under /usr/include/. I opened it by I didn't
understand for which version of libelf.so it is so I tried to rebuilt
Dyninst once with .so.0 and once with .so.1.
With .so.0 Dyninst installation completed successfully, the compilation
of the injecter was successful but the execution was fatal:
cmake /home/gon1332/Development/Repositories/dyninst
-DBOOST_ROOT=/usr/local -DLIBDWARF_INCLUDE_DIR=/usr/local/dwarf
-DLIBDWARF_LIBRARIES=/usr/local/lib/libdwarf.so
-DLIBELF_INCLUDE_DIR=/usr/include/libelf.h
-DLIBELF_LIBRARIES=/usr/lib/x86_64-linux-gnu/libelf.so.0
./func_instr
--FATAL-- #68: Dyninst was unable to create the specified process
--FATAL-- #68: create process failed bootstrap
[1]28984 segmentation fault (core dumped) ./func_instr
With .so.1
cmake /home/gon1332/Development/Repositories/dyninst
-DBOOST_ROOT=/usr/local -DLIBDWARF_INCLUDE_DIR=/usr/local/dwarf
-DLIBDWARF_LIBRARIES=/usr/local/lib/libdwarf.so
-DLIBELF_INCLUDE_DIR=/usr/include/libelf.h
-DLIBELF_LIBRARIES=/usr/lib/x86_64-linux-gnu/libelf.so.1
./func_instr
--SERIOUS-- #100: Image: Unable to find function: foo
Hello, world!
Either way I had problems. How could I by sure about my header file?
Thanks a lot.
On 28/07/2015 07:15 μμ, Matthew LeGendre wrote:
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 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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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 in
Re: [DynInst_API:] Cannot find function
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 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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@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
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
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:] Cannot find function
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 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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@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
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Re: [DynInst_API:] Cannot find function
With this mutatee and git-head locally, the following sequence:
BPatch bp;
BPatch_binaryEdit* be = bp.openBinary(argv[1]);
std::vector 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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@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
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Re: [DynInst_API:] Cannot find function
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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
Konstantelias Ioannis
Undergraduate at
Department of Electrical and Computer Engineering
University of Thessaly, Greece
hello
Description: Binary data
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Re: [DynInst_API:] Cannot find function
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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Re: [DynInst_API:] Cannot find function
Sorry,
My bad. I should've tell you. I've also tried includeUninstrumentable =
true but the results were the same.
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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at
func_instr.cc:50
50points = 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
0040057d 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@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
Konstantelias Ioannis
Undergraduate at
Department of Electrical and Computer Engineering
University of Thessaly, Greece
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Re: [DynInst_API:] Cannot find function
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
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
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 0x746af700 (LWP 23032)]
[New Thread 0x73eae700 (LWP 23033)]
[New Thread 0x734a4700 (LWP 23034)]
*--SERIOUS-- #100: Image: Unable to find function: foo*
Program received signal SIGSEGV, Segmentation fault.
0x004018c7 in findEntryPoint (app=0x63c100) at func_instr.cc:50
50points = 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
0040057d 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@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
