[PATCH] D41926: [DWARFv5] CodeGen support for MD5 checksum

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

So, the checksum will come in from the front-end as a string in DIFile.  It wants to be binary in the .o file.  What happens in-between is maybe not optimal, but has to address a couple of considerations.
First, where is it stored and who owns the memory?  As a StringRef it's not clear, but as an MD5Result it really ought to be owned by MCContext (the CodeView path does the same thing).  AsmPrinter does this allocation and conversion.
Second, from AsmPrinter it goes to "the streamer" which might be emitting an object file or might be emitting a text file, but AsmPrinter (despite its name) doesn't know which.  For type and memory safety I chose to have the MC API take an MD5Result* instead of yet another StringRef.  For emitting a text file, MCAsmStreamer converts it back to text, and then the AsmParser reads the text and converts it back to binary before passing it to "the (object-file) streamer."  AsmParser needs to validate the string when it does this conversion.  Then the object-file streamer has binary data and just emits it to the object file without any further fuss.  For emitting an object-file directly, AsmPrinter passes it along as binary data and there are no additional conversions in the path.

If we have the Verifier verify the DIFile's copy of the checksum, then the initial conversion in AsmPrinter can assume it's a hex string of the correct length and avoid a bit of checking.  AsmParser still needs to validate, but the direct-to-object path doesn't.

I hope that all made sense.  I have to re-train my brain every time I think about the different paths through here (and it gets even more convoluted if you have to get down into the nitty-gritty of object files, which fortunately we don't have to here).


https://reviews.llvm.org/D41926