In Codeview, the basic type of a complex represents the size of an individual component rather than the sum of the real and imaginary components.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
When describing a Fortran complex type in Codeview, use the size of an individual component rather than the sum of the real and imaginary components.
That seems very strange - why would the size of an entity be recorded as the size of only half of it?
Consider that Codeview includes an entry to describe an 80 bit complex. If the 80 bits was intended to represent the total size of the complex that would mean that the real and imaginary components of the complex are 40 bits each, requiring the existence of a 5-byte floating point value.
is that how MSVC describes such an entity? Or does it describe it as 160 bits? (or something else) & what does Clang do for something similar/equivalent?
The MS compiler does not directly support the complex or _Complex keywords. Instead, MS decided to implement complex number support using structure types so cl emits a structure type in the debug info rather than using one of the Codeview complex basic types. On Windows, clang seems to follow cl here.
+@hansw for CV questions too.
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1796–1797 | When you say "The CodeView size" what do you mean? The size that some frontend is encoding in the size in the LLVM IR debug info metadata? Is it possible that the bug is in the frontend, rather than here? (& looking at the boolean case above, I guess these SimpleTypeKind::*N are N in bits? Is that tru efor Boolean and Complex?) I guess a broad question: Where's the data coming from that informs what's correct and motivates this patch/change? |
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1796–1797 | By "The CodeView size" I mean the size that appears as part of the name of the SimpleTypeKind enum, and yes these numbers represent bit size for both Boolean and Complex. These enums are defined in TypeIndex.h and relate back to the enums defined in the cvinfo.h file uploaded to github by MS under microsoft-pdb. No, I don't think there is a front end bug here. It's just the Codeview entry for complex can seem a bit different than the other numeric leaves. As for where the data comes from, under the microsoft-pdb github you can also find a link to a document called Microsoft Symbol and Type Information. In that document, under the section "Numeric Leaves", you can find the definition for the Complex entries. |
Looking at the docs, it does seem like e.g. "32-bit Complex" refers to a type with 16-bit real + 16-bit imaginary in this context.
In the end, the proof of the pudding is what the debugger expects. @smerritt have you been able to check whether this is what the debugger wants?
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1798–1799 | What happens if ByteSize is 2 here now? Should we assert? | |
llvm/test/DebugInfo/COFF/fortran-basic.ll | ||
1 | I assume the file mode change is unintentional? |
Unfortunately, neither the Visual Studio debugger (no extensions installed) nor WinDbg appear to be capable of displaying the value of variables encoded with one of the complex numeric leaves, even for C code. Given that the MS C compiler doesn't emit these and they no longer have a Fortran compiler, its not completely surprising. The Visual Studio debugger will display these values for Fortran variables if the Intel Fortran Expression Evaluator extension is installed into VS. I don't know of any other Windows debuggers still in production that will display these variables.
llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1798–1799 | Any unrecognized sizes coming through this routine for any of the basic types will result in the type of the associated variable being "None". This means the variable will still be present in the debug info but it's type will be unknown so a debugger won't know how to display its value. A user still be able to see the variable exists and might be able to use a typecast in the debugger to inspect that value. | |
llvm/test/DebugInfo/COFF/fortran-basic.ll | ||
1 | Yes, I'll fix that. |
Fix similar size determination code in TypeRecordHelpers.cpp.
Reduce diffs in LIT test, adding back opaque pointer markers.
Sorry for the extra patch but I noticed similar code in TypeRecordHelpers.cpp and thought I should fix it.
When you say "The CodeView size" what do you mean? The size that some frontend is encoding in the size in the LLVM IR debug info metadata? Is it possible that the bug is in the frontend, rather than here?
(& looking at the boolean case above, I guess these SimpleTypeKind::*N are N in bits? Is that tru efor Boolean and Complex?)
I guess a broad question: Where's the data coming from that informs what's correct and motivates this patch/change?