This is an archive of the discontinued LLVM Phabricator instance.

[Codeview] Fix incorrect size determination for complex types.
ClosedPublic

Authored by smerritt on Feb 10 2023, 9:34 AM.

Details

Summary

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.

Diff Detail

Event Timeline

smerritt created this revision.Feb 10 2023, 9:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2023, 9:34 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
smerritt requested review of this revision.Feb 10 2023, 9:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2023, 9:34 AM

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.

I'm going to be updating this patch as I see the issue is not limited to Fortran.

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.

smerritt updated this revision to Diff 498035.Feb 16 2023, 8:31 AM
smerritt retitled this revision from [Codeview] Fix incorrect size determination for Fortran complex types. to [Codeview] Fix incorrect size determination for complex types..
smerritt edited the summary of this revision. (Show Details)

Update to make the fix general case.

dblaikie added a subscriber: hansw.Feb 16 2023, 9:31 AM

+@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?

smerritt added inline comments.Feb 16 2023, 12:27 PM
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.

hans added a subscriber: hans.Feb 17 2023, 6:00 AM

+@hansw for CV questions too.

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.

smerritt updated this revision to Diff 498365.Feb 17 2023, 7:25 AM

Fix file permissions.

hans accepted this revision.Feb 20 2023, 5:35 AM

lgtm

This revision is now accepted and ready to land.Feb 20 2023, 5:35 AM
smerritt updated this revision to Diff 499477.Feb 22 2023, 6:43 AM
smerritt added a reviewer: CarlosAlbertoEnciso.

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.

hans accepted this revision.Feb 23 2023, 7:21 AM

still lgtm

This revision was landed with ongoing or failed builds.Feb 24 2023, 6:32 AM
This revision was automatically updated to reflect the committed changes.