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

[David Blaikie via llvm-commits]

On Sat, May 21, 2016 at 10:17 AM, Davide Italiano via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> davide added a comment.
>
> 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)
>

Generally we try to separate which things are tested - granted that gets
fuzzy with the tools we use for testing (so we want to use readobj to test
some llvm-mc feature - so we can't isolate the testing of each entirely).
If we're missing llvm-mc testing, we should add it.


> 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)
>

I'm not quite following here - if something breaks in the toolchain why
would we need to regenerate the llvm-readobj test? We might need to add new
tests to make sure readobj can handle the new/different/possibly broken
input in some sane way, but unless we discover that the original test was
incorrect we shouldn't need to regenerate it, right?


> 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.
>

Then lets make sure we add/maintain the comments - part of code review, etc
(in the same way that "don't use a binary test" would be code review
feedback we'd provide if we went that way).

We certainly don't have hard and fast rules here (& for some tools like
dwarfdump/readobj/etc we can be a bit lax on testing, treating them as just
testing/dev tools, etc) - certainly there are varying opinions (eg: the use
of llvm-mc in lld tests rather than the standalone object file format (json
or whatever it was)) & we're always adjusting. So there's totally room to
discuss/debate.


>
> 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).
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D20273
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160522/b47f5f3a/attachment-0001.html>