[llvm] r243487 - [tests] Use llvm-readobj instead of macho-dump.

[Saleem Abdulrasool via llvm-commits]

On Wed, Aug 12, 2015 at 5:50 AM, Rafael Espíndola <
llvm-commits at lists.llvm.org> wrote:

> > I see what's your use case. I think this deserves a little bit more
> > discussion, and I would like to hear what Saleem and Rafael have to
> > say about it (or others, as well), but what do you think about
> > introducing a flag --continue-on-error so that:
> > 1) by default, we bail out early and notice immediately to the user
> > the object is broken.
> > 2) for people who want to investigate and understand what's broken,
> > they turn on the flag and get the (potential) garbage printed.
> >
>
> I don't think we should have that flag. What I think we should do to
> make llvm-readobj well behaved on invalid files is
>

Whole heartedly agree.


> * Make it read as least as possible. I already did some of that so
> that, for example, it doesn't fail on a file with a broken dynamic
> table if you are not printing the dynamic table.
>

Do you mean read as little as possible to do the job it needs to?  Id
rather read as *much* as possible though.  Consider cases of static
archives.  Just because the n-th element is corrupt, doesn't mean that we
shouldn't inspect the n+1-th item.  Of course, this is something that needs
to be handled on a case-by-case basis.  Obviously if you are inspecting a
single ELF object file, and the section header is corrupt, then we have no
way to get to the sections and we cannot do anything involving the sections.


> * Have good error messages. Right now most of the errors are just
> "parse error". We can do a lot better by adding a diagnostic handler.
> This is in my todo list.
>

Not to put words in Joerg's mouth, but I think that this would go a long
way to alleviate his concern.  If we can provide concrete messages of
*what* went wrong, then the tool becomes significantly more invaluable,
since it can analyse the failure.


> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150812/14f80998/attachment.html>