[PATCH] D41846: [DWARFv5] MC support for MD5 checksum

[David Blaikie via llvm-commits]

On Tue, Jan 9, 2018 at 9:30 AM Paul Robinson via Phabricator <
reviews at reviews.llvm.org> wrote:

> probinson added inline comments.
>
>
> ================
> Comment at: llvm/include/llvm/MC/MCDwarf.h:56
> +  /// The MD5 checksum, if there is one.
> +  MD5::MD5Result *Checksum = nullptr;
>  };
> ----------------
> aprantl wrote:
> > Optional<MD5::MD5Result>?
> This is a non-owning pointer to data allocated in MCContext.  Does that
> change your opinion?  (Or Blaikie's?)
>

Roughly sounds OK to me, with some comments about that (and/or maybe a
typedef/opaque handle type or something - and document the ownership where
that type is defined)


>
>
> ================
> Comment at: llvm/lib/MC/MCParser/AsmParser.cpp:3361
> +      Checksum = fromHex(Checksum);
> +      assert(Checksum.size() == 16);
> +      CKMem = (MD5::MD5Result *)Ctx.allocate(sizeof(MD5::MD5Result), 1);
> ----------------
> aprantl wrote:
> > I think I would feel more comfortable with a report_fatal_error on
> invalid inputs.
> Potentially being user input, this ought to be using the check() mechanism
> instead of an assertion.  Sorry about the brain-lapse here.
>
>
> ================
> Comment at: llvm/test/MC/ELF/debug-md5.s:4
> +        .file 1 "dir1/foo"   md5 "00112233445566778899aabbccddeeff"
> +        .file 2 "dir2" "bar" md5 "ffeeddccbbaa99887766554433221100"
> +        .loc 1 1 0
> ----------------
> aprantl wrote:
> > Just out of curiosity: why did you opt for a string literal instead of a
> hex numeral? Is there some precedent for that?
> I believe .cv_file does it that way (the CodeView version of .file).  IIRC
> the integer-parsing functions don't have a way to return a 128-bit result.
> Handled as a string, I can parse it directly into the allocated MD5Result.
>
>
> https://reviews.llvm.org/D41846
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180109/a30e03fe/attachment.html>