I am debugging a C program on arm64 with lldb and in order to implement my own debugging function I wrote a standalone debug helper program, compiled it as a dylib and imported it into lldb by using:
(lldb) target modules add debugHelper.dylib
However when I call the function declared in the dylib, lldb errors:
(lldb) expression debugPrint()
error: Couldn't lookup symbols:
_debugPrint
If I type in a random function name (e.g. foo):
(lldb) expression foo()
error: use of undeclared identifier 'foo'
, which makes me believe importing the dylib is indeed successful, since debugPrint
is not an undeclared identifier
.
// debugHelper.c
#include <stdio.h>
int debugPrint() {
printf("%s\n", "Debug info printed! \n");
return 0;
}
debugHelper.dylib is compiled with:
$ xcrun --sdk iphoneos cc debugHelper.c -o debugHelper.dylib -dynamiclib -arch arm64 -g
I also verified with nm
that debugHelper.dylib does have the _debugPrint
symbol:
$ nm debugHelper.dylib
0000000000007f2c T _debugPrint
U _printf
U dyld_stub_binder
Results of (lldb) image list
:
[263]... debugHelper.dylib.dSYM/Contents/Resources/DWARF/debugHelper.dylib
target modules add
loads the binary (and its dSYM, if there is one) into lldb's pool of binaries it knows about. But the dylib has not been loaded into your inferior process -- you will not be able to run the functions in there.
Instead, run dlopen()
in your process:
(lldb) p (int)dlopen("debugHelper.dylib", 10)
(that 10 is RTLD_GLOBAL|RTLD_NOW
, v. dlfcn.h
). There's also an SB API method to do this, SBProcess::LoadImage
which doesn't require you to look up the details of dlopen
. e.g.
(lldb) script lldb.process.LoadImage(lldb.SBFileSpec("debugHelper.dylib", False), lldb.SBError())