I have build lldb from llvm tag 14.0.4 on linux (tested on archlinux latest and centos 7), but it cannot step into function of shared library but gdb could.
This is a minimal example
// main.cpp
#include "mylib.h"
int main(int argc, char *argv[]) {
add(argc, argc ^ 0xFF);
add(argc, argc ^ 0xFF);
return 0;
}
// mylib.h
int add(int a, int b);
// mylib.cpp
int add(int a, int b) {
return a ^ b & b;
}
The makefile is
all:
clang++ mylib.cpp -O0 -g3 -shared -fpic -o mylib.so
clang++ main.cpp -O0 -g3 mylib.so -o main
After building the program, you can use LD_LIBRARY_PATH=. lldb main
to load the program into lldb and reproduce the problem with the following steps
b main
to set a breakpoint at main functionr
to start the programadd(argc, argc ^ 0xFF);
, press s
to step into source, but you will get into assemble, a demo output will like(lldb) s
Process 15758 stopped
* thread #1, name = 'main', stop reason = step in
frame #0: 0x0000000000400500 main`add(int, int)
main`add:
-> 0x400500 <+0>: jmp qword ptr [rip + 0x200b22] ; _GLOBAL_OFFSET_TABLE_ + 40
0x400506 <+6>: push 0x2
0x40050b <+11>: jmp 0x4004d0
main`_start:
0x400510 <+0>: xor ebp, ebp
If you use gdb to debug the program, gdb will step you into add
function rather than assemble codes.
I have tried lldb on macOS 12.5, it works fine.
This problem was reported to the lldb bug tracker:
https://github.com/llvm/llvm-project/issues/54250
It seems to have been a bug in some of the 14.x versions of lldb on Linux, but the originator of that bug said it was fixed in 15.0 and the TOT lldb's.