labath wrote:
> It is the combination of the first and third. For completeness.
>
> we do an step-over, which lands us at an instruction, which happens to be the
> first instruction of an inlined function. lldb-dap takes the PC value and
> resolves it to a function/block on its own. This returns the inlined function
> line entry (because the resolving function tries to be as accurate as
> possible).
>
> This only happens in lldb-dap not lldb.
okay, so would something like this be sufficient to reproduce the issue (you
can put the functions in different files as needed):
```
void __attribute__((noinline)) fn1() {}
void __attribute__((always_inline)) fn2() { fn1(); }
int main() {
fn1();
fn2();
}
```
Stop and the `fn1` line, step over the call to fn1(), which should land you at
the call to fn1 (inlined through fn2, you can use a different function to make
it clearer). lldb-dap should show you stopped at the fn2() line. Probably best
to build the whole program with -O1 (CFLAGS_EXTRAS=-O1), to ensure the compiler
doesn't insert any unnecessary goo between the two calls.
https://github.com/llvm/llvm-project/pull/143644
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
