[LLDB on windows] Step out is not working

Hello,

Compile this sample program with clang 3.9.1 in 64bits mode
#include

int my_func(char c, double d)
{
std::cout << "c: " << c << std::endl;
std::cout << “d:” << d << std::endl;
return 0;
}

int main(int argc, char const *argv[])
{
int i = 0;
i++;
i++;
my_func(‘a’, 10.1);
i++;
i++;

return 0;
}

compile commande line :
clang++ -x c++ -target “x86_64-pc-windows-msvc” -O0 -glldb -gdwarf-4 -D _WIN32 -D _WIN64 -D _CONSOLE -D NDEBUG -D _DEBUG -D _MT -D _DLL -c -o main.o main.cpp
lld-link /out:main.exe /machine:X64 /nxcompat /incremental /nologo /wx /subsystem:console /debug vcruntimed.lib msvcrtd.lib main.o

run lldb and enter commands
target create “main.exe”
b main.cpp:14
r

First step over (n command) is ok but second step over goes into my_func function.

Thanks,

Olivier

I presume you meant "step over is not working" in the Subject?

The call to std::cout... ends up inserting quite a number of inlined function calls into my_func. clang is not always great at generating coherent line-table and inlined subroutine ranges for deeply nested inlining, so that the stepping machinery can't safely figure out how to get out of the inlining, and ends up stopping. This example actually works correctly on macOS with a recent clang, but this has been an ongoing issue for a while now.

lldb currently always implements "step over" as "step in" followed by "step out". This saves us the (sometimes surprisingly tricky) work of predicting where a particular call will go, and where it will return to. But it does leave us vulnerable to errors in the debug information at the callee site. It would be nice to add a set of "vanilla" calls that we're sure we can predict, and for those we could just break on the return address and not even bother to step in. That would likely remove this sort of stumble in a lot of cases.

OTOH, you should still file a bug about this. As I said, this works correctly on current TOT lldb/clang 802 on macOS. So it may also be some issue with the Windows port unrelated to this debug info problem.

Jim