dblaikie added a comment.
>> - We could supply a test written in C, but it needs -O1 and is fairly
>> sensitive to the meaning of -O1 (e.g., clang started inlining and omitting
>> unsued inlined parameters only recently, so changes to -O1 could make a C
>> test easily meaningless). Any concerns here?
>
> It is really hard to make sure the compiler generates what you want for a
> test case as it will change over time and you might not end up testing what
> you think you are testing. The easiest way to avoid this is to emit the
> assembly from the compiler and then use that as the source for the test since
> that will guarantee the same output.
If anyone ever needs a hand constructing a stable debug info test case using
clang (or other compilers for that matter) - I'm totally happy to help. It's
quite possible to constrain the compiler enough and give it easy enough things
to inline to make it pretty reliable - for instance for this sort of issue, I'd
expect something like this is what I'd use to demonstrate a missing parameter:
__attribute__((optnone)) __attribute__((nodebug)) void use(int*) { }
inline void f1(int a, int b) {
use(&b);
}
int main() {
f1(5, 6);
}
This compiled with some optimizations (-O1 or above should be adequate) should
result in a single concrete subprogram for main, a single inlined subroutine
with a single formal parameter in the inlined subroutine (for 'b') and the
abstract origin will have both 'a' and 'b'.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110571/new/
https://reviews.llvm.org/D110571
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
