[PATCH] D20273: [llvm-readobj] - Teach readobj to recognize SHF_COMPRESSED flag.

[George Rimar via llvm-commits]

grimar added a comment.

In http://reviews.llvm.org/D20273#436361, @davide wrote:

> I'm still convinced (for many reasons) that checking in a binary isn't a great option when we can use MC.
>  I don't think "excessive dependencies like asm->llvm-mc->zlib" is a strong argument as we have them anyway.
>  OTOH, using our tools instead of a binary allows:
>
> 1. dogfooding (which might catch regression)


I think in this patch we do not want to test llvm-mc, we want to check that proper flag is dumped from valid object. Since object is one time commited and
therefore always is valid, regression might be only because of changes in readobj code. If we would want to check that llvm-mc
generates proper flags, it should be test for llvm-mc, but not readobj.

> 2. easier changes in case something breaks in the toolchain (we don't need to generate the binary again, we can just change the test)


We probably never need to gererate binary again except if it was incorrect initially.

> 3. readability (you can read the ASM instead of a description). Maybe it's not the case but from time to time precompiled binaries lack a comment which describes how they've been generated, and comments and binary can get out of sync quickly.


Sometimes yes, we can read, but speaking of this patch you not only would not find anything about SHF_COMPRESSED flag in asm, but also would need to read llvm-mc command line
to find was compression set or not and also know what style of compression was used, was it zlib (which sets the flag) or zlib-gnu, which don't. So it would be a huge pain here.

> In other words, I'm always for using llvm-mc instead of a binary (unless there's a strong reason not to). I'd rather bit the bullet and implement the missing feature in the assembler instead of going through the binary route which may lead to bigger pain later (I had to generate again ~10 binaries in DebugInfo tests in order to fix a bug in the verifier recently).


So my opinion that sometimes it is profitably to use llvm-mc, but sometimes - not.
(Just in case, are you aware that zlib on windows is broken >= 2 years ? https://llvm.org/bugs/show_bug.cgi?id=19403, so use of llvm-mc for this test would just skip
running testcases on whole windows world). That is what I thinkg a good example of excessive dependency on llvm-mc.


Repository:
  rL LLVM

http://reviews.llvm.org/D20273