labath added a subscriber: dblaikie.
labath added a comment.
Actually, there was a subtle change of behavior here. Before this change, if we
tried to parse a DIE using an abbreviation table from a different file, we
would most likely fail immediately because of the fail-safe in
GetAbbreviationDeclarationPtr. Now, we just do a blind read and return bogus
data.
Now, normally this shouldn't matter, but in case of split-dwarf, things start
to get interesting. Lldb has this assumption that when we are reading a debug
info entry (which is not the CU DIE), we are actually reading it from the dwo
compile unit and not the skeleton unit in the main file. This means it uses the
dwo abbreviation list and everything. Now, as far as I can tell, LLDB is kind
of right here. The DWARF5 (in v4 split dwarf was a non-standard extension) spec
says "A skeleton compilation unit has no children." (3.1.2 Skeleton Compilation
Unit Entries). And indeed, gcc produces compilation units with no children.
Clang, on the other hand, seems to be putting some DIEs into the main CU,
**if** the compilation results in functions being inlined. And it seems clang
has been doing this since at least 7.0 (I haven't tried older versions).
So it seems we have two problems here:
1. We need to figure out whether there's a bug in clang and fix it. + @dblaikie
for help with that
2. Depending on the outcome of the first item, we need to do something in lldb
to handle this. If this is a clang bug (and my feeling is that it is), then the
best solution might be to just start ignoring any non-CU dies from the main
file in split-dwarf scenario
@dblaikie: Do you agree with my assessment above? If this is indeed a clang
bug, any chance you could help with debugging the clang/llvm side of things?
The simplest reproducer for this would be something like:
inline __attribute__((always_inline)) int foo(int x) { return x; }
int main(int argc) { return foo(argc); }
`$ clang++ a.cc -c -o a.o -g -gsplit-dwarf`
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62634/new/
https://reviews.llvm.org/D62634
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
