[lldb/DWARF] Downgrade the "parent of variable is not CU" error #108806
Conversation
|
@llvm/pr-subscribers-lldb Author: Pavel Labath (labath) ChangesThis can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error. The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ". We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does not print this error message, but it doesn't seem like it would be particularly useful. Full diff: https://github.com/llvm/llvm-project/pull/108806.diff 1 Files Affected:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index f721ca00fd3559..082c437321e38b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3828,10 +3828,8 @@ void SymbolFileDWARF::ParseAndAppendGlobalVariable(
break;
default:
- GetObjectFile()->GetModule()->ReportError(
- "didn't find appropriate parent DIE for variable list for {0:x8} "
- "{1} ({2}).\n",
- die.GetID(), DW_TAG_value_to_name(die.Tag()), die.Tag());
+ LLDB_LOG(GetLog(DWARFLog::Lookups),
+ "DIE {0:x8} is not a global variable - ignoring", die.GetID());
return;
}
|
Use a `nullptr` map entry to mean "variable parse was attempted and it failed" an the absence of an entry to mean "parsing hasn't been attempted yet". I ran into this because parsing of function-static variables was generating a lot of errors (see llvm#108806), but this seems like a good idea in general. In theory this should be NFC, except for possibly reducing some amount of work.
|
Adding these to the manual index is very easy -- there just isn't a point in doing it (except maybe for consistency). In case I wasn't clear: this warning/error appears in the compiler-generated indexes, because we find the variable in the name lookup -- and then ignore it. |
|
One more clarification :P I think it would be reasonable for something like |
|
Ahh thanks for the clarification. Makes sense. Sounds like a situation where this would arise is: Doing I guess the alternative would be to suppress the error message only if the parent is a So LGTM. |
| "{1} ({2}).\n", | ||
| die.GetID(), DW_TAG_value_to_name(die.Tag()), die.Tag()); | ||
| LLDB_LOG(GetLog(DWARFLog::Lookups), | ||
| "DIE {0:x8} is not a global variable - ignoring", die.GetID()); |
There was a problem hiding this comment.
Nit: should we include the name/tag too? I could see it being useful
This can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error. The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ". We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does *not* print this error message, but it doesn't seem like it would be particularly useful.
…#108806) This can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error. The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ". We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does *not* print this error message, but it doesn't seem like it would be particularly useful.
…#108806) This can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error. The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ". We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does *not* print this error message, but it doesn't seem like it would be particularly useful. (cherry picked from commit 1f8e662)
…#108806) This can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error. The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ". We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does *not* print this error message, but it doesn't seem like it would be particularly useful. (cherry picked from commit 1f8e662)
This can legitimately happen for static function-local variables with a non-manual dwarf index. According to the DWARF spec, these variables should be (and are) included in the compiler generated indexes, but they are ignored by our manual index. Encountering them does not indicate any sort of error.
The error message is particularly annoying due to a combination of the fact that we don't cache negative hits (so we print it every time we encounter it), VSCode's aggresive tab completion (which attempts a lookup after every keypress) and the fact that some low-level libraries (e.g. tcmalloc) have several local variables called "v". The result is a console full of error messages everytime you type "v ".
We already have tests (e.g. find-basic-variable.cpp), which check that these variables are not included in the result (and by extension, that their presence does not crash lldb). It would be possible to extend it to make sure it does not print this error message, but it doesn't seem like it would be particularly useful.