Ensure the TemplateParam attribute of the DIGlobalVariable node is translated into the proper DIEs.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Since you're changing the IR please also add a round-trip test (llvm-as | llvm-dis | llvm-as | llvm-dis).
include/llvm-c/DebugInfo.h | ||
---|---|---|
977 ↗ | (On Diff #165366) | The C-API is considered stable. You could extend it if you have a use case for this? |
include/llvm-c/DebugInfo.h | ||
---|---|---|
977 ↗ | (On Diff #165366) | Not currently. I'm happy removing this part of the change. |
test/DebugInfo/X86/template.ll | ||
---|---|---|
6–9 ↗ | (On Diff #165788) | I'm guessing this source code is out of date, since it doesn't appear to include a global variable template named 'var'? |
20 ↗ | (On Diff #165788) | Presumably this should actually be named 'var<int>'? Not a big deal, since this is just using whatever name is in the IR To begin with - but might make the test case less confusing. |
test/DebugInfo/X86/template.ll | ||
---|---|---|
6–9 ↗ | (On Diff #165788) | Yep. That's out of date. Will fix. |
test/DebugInfo/X86/template.ll | ||
---|---|---|
20 ↗ | (On Diff #165788) | In this case, the template parameters are not added to the variable name. |
test/DebugInfo/X86/template.ll | ||
---|---|---|
20 ↗ | (On Diff #165788) | Why's that? The parameters are part of the variable name for class and function templates - seems they'd be necessary/useful to disambiguate for variable templates too. (though I do see that GCC (8.1) also doesn't seem to put template parameters on variable templates... ) |
test/DebugInfo/X86/template.ll | ||
---|---|---|
20 ↗ | (On Diff #165788) | Correction: It breaks global variable look up, not global symbol lookup. |
Thanks!
test/DebugInfo/X86/template.ll | ||
---|---|---|
20 ↗ | (On Diff #165788) | Fair enough - not a bug to be fixed here anyway. Hopefully LLDB is tracking the fix for that & Clang can switch over after that. Assuming it works for GDB. (though perhaps it'd be best to make this test case look like the expected name (rather than the bug-workaround name) - so as to be less surprising to folks working on LLVM/reading this in the future?) |