I’d like to use lldb’s backtrace as a library as opposed to using lldb program, so that I can generate good stack traces inside a C/C++/D program without having to spawn a separate process that would call ‘lldb -p pid’.
How should I proceed? Or, what is the relevant function call?
Actually I just realized I’ve posted a related question before: “process calling lldb to symbolicate its own backtrace”.
However it didn’t seem so easy to do judging from the thread. Has anything changed since then? There should be a simple way to do this important task.
This should get you started:
You will link against LLDB.framework on MacOSX, or liblldb.so on unix, or liblldb.dll on windows.
The you would do:
using namespace lldb;
int main(int argc, const char * argv)
if (argc != 2)
printf ("usage: backtrace <pid>\n");
const bool source_init_files = true;
SBDebugger debugger = SBDebugger::Create(source_init_files);
debugger.SetAsync (false); // Set debugger to synchronous mode
const char *filename = NULL; // Fill this in if you know the filename, else leave NULL
const char *target_triple = "x86_64";
const char *platform_name = NULL; // Leave NULL
bool add_dependent_modules = true; //
lldb::pid_t pid = (int)strtol(argv, (char **)NULL, 10);
SBAttachInfo attach_info (pid);
SBTarget target = debugger.CreateTarget (filename, target_triple, platform_name, add_dependent_modules, error);
SBProcess process = target.Attach (attach_info, error);
uint32_t num_threads = process.GetNumThreads();
for (uint32_t thread_idx=0; thread_idx<num_threads; ++thread_idx)
SBThread thread = process.GetThreadAtIndex(thread_idx);
uint32_t num_frames = thread.GetNumFrames();
for (uint32_t frame_idx=0; frame_idx<num_frames; ++frame_idx)
SBFrame frame = thread.GetFrameAtIndex(frame_idx);
fprintf(stderr, "error: failed to attach to process: %s\n", error.GetCString());
fprintf(stderr, "error: failed to create target: %s\n", error.GetCString());
No, nothing has changed. lldb only operates in "control other process" mode, not in "observe other process" mode, and controlling yourself is a neat trick you might be able to manage, but would add a lot of complexity for no clear benefit for most of the usages of lldb.
On OSX, you can use CoreSymbolication to take a backtrace of yourself. There are likely similar facilities on other systems.
backtrace/backtrace_symbols /atos(osx)/addr2line(linux) is not a viable
alternative, as it doesn't give proper/accurate line numbers in many cases,
unlike what lldb provides.