[PATCH] D41606: [COFF] support /ignore:4217

[Zachary Turner via llvm-commits]

Yea the nice thing about yaml for codeview is you can write it with c++,
compile with cl, dump the records with llvm-pdbutil, and then copy/paste
the codeview records into a test. That’s hard / impossible with an mc test.

It’s probably possible to add an ‘assembly’ output style, but not sure if
it’s worth the effort
On Thu, Dec 28, 2017 at 9:07 AM Reid Kleckner via Phabricator <
reviews at reviews.llvm.org> wrote:

> rnk added a subscriber: zturner.
> rnk added a comment.
>
> In https://reviews.llvm.org/D41606#964821, @smeenai wrote:
>
> > General question: it looks like a lot of COFF tests are written using
> yaml2obj, whereas ELF always uses assembly files and llvm-mc (and I've been
> following that pattern for the few COFF patches I've written as well). Is
> there an actual preference for yaml2obj tests in COFF, or is it just a
> historic artifact? I personally find assembly tests a lot easier to
> understand.
>
>
> I agree, I'd recommend using .s files for all non-PDB tests. I use yaml
> mostly for objects with codeview because it @zturner added a great symbolic
> representation for codeview.
>
> However, our COFF yaml isn't a very good representation for code and
> relocations. Code is represented as a binary blob and relocations are
> stored on the side. Storing relocations separately is a problem for
> codeview symbol records because if you want to add one record, you have to
> determine its size and update the offsets of all the relocations after the
> symbol. Type records don't have this problem because they do not contain
> relocations. Type merging is significantly more complicated than symbol
> linking, so we naturally have more tests for it, and increasing the
> testability of symbol records hasn't been as much of a priority.
>
> The best way to unify these tests would probably be to add more directives
> to MC to emit complete codeview records. We can still test invalid records
> by falling back to open coding them with .byte, .short, and .long data
> directives.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D41606
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171228/8a16f35a/attachment.html>