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

[Davide Italiano via llvm-commits]

On Sun, Aug 9, 2015 at 6:54 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Aug 05, 2015 at 07:49:33AM -0400, Rafael Espíndola wrote:
>> > Sure. The last beast to tackle is llvm-objdump. I'm cool with doing
>> > the conversion but I wanted to hear your opinion. I think that
>> > llvm-readobj is more of a tool for the final user so it makes sense to
>> > continue on error rather than calling exit(1). What's your opinion,
>> > and, if you know, what's the GNU behavior in this case?
>>
>> When creating invalid object files for tests I noticed that tools like
>> readelf normally print an error/warning and then proceed to print
>> garbage or crash.
>>
>> IMHO users are better served by a good error message and a full stop,
>> so IMHO exit(1) is better for llvm-objdump too.
>
> I have a somewhat different position. It is highly annoying if you have
> a slightly broken object file and you can't figure out what is broken,
> because your tools keep crashing or outright rejecting it. Printing
> garbage after an error message is OK to a degree, but please avoid
> bailing out too early. Another item to consider is whether to bail out
> of the current logical group. E.g. if you run into some inconsistency in
> the program header, it might still be possible and reasonable to print
> the symbol table.
>
> Joerg

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.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare