Fix Bug 30978 by emitting cv file checksums.

[ecbeckmann]

Summary

The checksums had already been placed in the IR, this patch allows
MCCodeView to actually write it out to an MCStreamer.

[ecbeckmann]

llvm/lib/MC/MCCodeView.cpp

49

remove

62–63

remove comment

138

combine this all into one line

139

Don't reassign to S and just directly use Ret.first

154

add a comment explaining this function

155

remove

161

remove spaces here

167

remove these

173

+=4 for the string table offset

176

+1 for size, +1 for kind, +2 to align (maybe just replace that with alignTo for clarity)

179

remove logging, more comments to explain offset

182

add comment explaining that, since the checksum section has been emitted, we can assume the offsets have been finalized so we can assign them.

192–193

update this comment

195

remove these

205

yes remove this

248

add comment to explain, how it needs to use a MCFixup provided by EmitValueImpl

260

remove

263

create a temporary symbol to hold the offset once it is calculated

270

remove

283

a

420

r

462–463

change this comment

llvm/lib/MC/MCObjectStreamer.cpp

144

r

llvm/lib/MC/MCParser/AsmParser.cpp

3464

should be lower case for consistency

llvm/lib/MC/WinCOFFObjectWriter.cpp

725 ↗

(On Diff #114469)

r

llvm/tools/llvm-readobj/COFFDumper.cpp

910 ↗

(On Diff #114469)

r these

1020 ↗

(On Diff #114469)

r

1106 ↗

(On Diff #114469)

not needed

[ecbeckmann]

Make this entire thing easier to follow and understand.

llvm/lib/MC/MCCodeView.cpp

60

This is confusing to read, make it more intuitive

[ecbeckmann]

Fortunately this seems to work whether generating assembly or object

[ecbeckmann]

Why do we have to add placeholders for the checksum offsets? Aren't they just added in order, one after another?

Actually, the implementation of addFile hasn't assumed it is done in order, and you can actually add random fileNo's whenever you want. Therefore, we shouldn't assume they are always done in order, and we should allow for the case where we don't yet know the checksum offset.

[ecbeckmann]

Add checksum offset directive.

[ecbeckmann]

Restructrue, create real symbol not temp.

[ecbeckmann]

Remove errant errors.

[ecbeckmann]

Format

[ecbeckmann]

llvm/include/llvm/IR/DebugInfoMetadata.h

476–481

Unfortunately I need the actual enum values to correspond exactly to the checksum types flag integer values actually present in the codeview section, hence the strongly typed enum class. This is important because I will now be emitting the ChecksumKind as assembly directives as well as directly into the binary.

llvm/include/llvm/MC/MCCodeView.h

300–315

Yes, combined all this info into one vector. It's still useful to have a StringMap because we want to check if a filename is already used before making a new entry.

[ecbeckmann]

Reformat

[ecbeckmann]

Reformat.

[ecbeckmann]

llvm/lib/MC/MCCodeView.cpp

194–206

It was all debugging code that was unintended for review. Please disregard. Sorry again for not making this patch private to begin with.

462–466

Filenames renamed to Files, which is now a vector of a massive structure containing all offset and checksum information.

[ecbeckmann]

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

686–687

Update this FIXME to say that we do provide checksum file info, and what VS uses this for.

[rnk]

llvm/lib/MC/MCCodeView.cpp

169

I don't think you want to do this, this leaks the internal MCSymbol (file1, etc) to the assembler. Nothing in the assembly defines file1, so the assembly isn't very readable.

llvm/test/DebugInfo/COFF/inlining.ll

52

What I had in mind was that we'd add a directive like .cv_filechecksum_offset <fileid> and MCCodeView.cpp would internally implement it without leaking any labels to the caller. We could use a label difference of two symbols to implement the offset computation, but any symbols shouldn't leak out to the assembler.

[probinson]

llvm/include/llvm/IR/DebugInfoMetadata.h

476–481

If you need the enums to have specific values, e.g. because those values end up in the object file (hard to tell here but I think that's what you are saying), you should set the enum values explicitly. This documents the exact values you need (even if they happen to be sequential at the moment). Making it an enum class doesn't get you that.

llvm/lib/IR/DebugInfoMetadata.cpp

363

If you require exact correspondence between an enum and some array of strings, we usually do that with a .def file and macros. See for example Dwarf.def. As it is, the association between this array and the ChecksumKind values is implied rather than explicit. Safer to be explicit.

[rnk]

llvm/lib/MC/MCCodeView.cpp

68

Use MCContext::createTempSymbol to make sure these don't show up in the .obj symbol table.

[ecbeckmann]

Don't leak symbol into assembler, remove enum class, use createTempSymbol.

[ecbeckmann]

llvm/include/llvm/IR/DebugInfoMetadata.h

476–481

Remove enum class to explicitly define values.

llvm/lib/IR/DebugInfoMetadata.cpp

363

Okay this should probably be addressed in another patch as this patch did not introduce the array.

llvm/lib/MC/MCCodeView.cpp

169

Instead of emitting the symbol, we will emit the .cv_filechecksumoffset <fileno> directive.

[ecbeckmann]

Some formatting fixes.

[ecbeckmann]

Removed some last unnecessary changes.

[probinson]

A few minor commentary points; nothing huge. I've been looking at this mainly with the thought of having to do something similar for DWARF 5 eventually, but it seems likely there won't be a lot to leverage as CodeView and DWARF appear to associate the hashes with files pretty differently. Oh well.

llvm/include/llvm/IR/DebugInfoMetadata.h

476–481

And maybe a comment that these end up in the object file, so some well-meaning person doesn't come a long later and remove the "unnecessary" explicit values.

llvm/include/llvm/MC/MCStreamer.h

732

As long as you're changing the comment anyway, please remove the \brief.

778

Remove \brief.

[ecbeckmann]

llvm/test/DebugInfo/COFF/inlining.ll

52

implemented as such

[rnk]

Thanks, looks good!

llvm/include/llvm/MC/MCCodeView.h

302–303

Generally, if the comment describing the variable doesn't fit on one line, consider moving it before the variable. Then we won't end up with this awkard split after the *.

[ecbeckmann]

Changed some comments.

[ecbeckmann]

Updated comment formatting.