<div dir="ltr">On Wed, Aug 12, 2015 at 5:50 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I see what's your use case. I think this deserves a little bit more<br>
> discussion, and I would like to hear what Saleem and Rafael have to<br>
> say about it (or others, as well), but what do you think about<br>
> introducing a flag --continue-on-error so that:<br>
> 1) by default, we bail out early and notice immediately to the user<br>
> the object is broken.<br>
> 2) for people who want to investigate and understand what's broken,<br>
> they turn on the flag and get the (potential) garbage printed.<br>
><br>
<br>
</span>I don't think we should have that flag. What I think we should do to<br>
make llvm-readobj well behaved on invalid files is<br></blockquote><div><br></div><div>Whole heartedly agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Make it read as least as possible. I already did some of that so<br>
that, for example, it doesn't fail on a file with a broken dynamic<br>
table if you are not printing the dynamic table.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Have good error messages. Right now most of the errors are just<br>
"parse error". We can do a lot better by adding a diagnostic handler.<br>
This is in my todo list.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>