Add more error checking to llvm-objdump and MachODump

[Kevin Enderby via llvm-commits]

I’m with Pete on this one.  I would rather in program code have an error() call if it wants to print a bunch of errors and then allow code up stream to determine if it wants to move on by testing the program global HadError that got set in error().  If there is something can’t be continued have something like fatal_error() that does the exit(1).  Then the program code can chose the model that works best for it.

For me it is extremely common to see broken .o files and that is what I do for a living.  And I write these tools for me to do my job.  If others find them useful great!  But they are needed to look at good and bad .o files.

My thoughts,
Kev

> On Dec 14, 2015, at 3:05 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> 
> 
>> On Dec 14, 2015, at 2:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> 
>> On 14 December 2015 at 17:28, Pete Cooper <peter_cooper at apple.com> wrote:
>>> Hi Rafael
>>> 
>>> This is the start of error handling when we encounter errors in __eh_frame parsing.
>>> 
>>> I add a bool return to printMachOEHFrameSection which returns true if we printed an error.  This is then propagated all the way up the call stack to main().
>>> 
>>> I think returning a bool makes more sense that report_fatal_error as upon getting an error, we want to continue to dump other sections, and even other eh_frame entries.  I do check this error and ensure we return 1 from main though.
>> 
>> Please just use fatal errors.
> The problem with that is that it gives us no error recovery.  I now get a single error and have to quit via exit(1).
> 
> Is that the model we’re planning on using for all of the tools?
> 
> Personally I was hoping for something more like clang where if my code contains some errors I can recover and see what comes next.
> 
> BTW, i’m not disagreeing with what you say below.  Propagating errors is certainly harder to work with that fatal errors, but I do like the ability to recover.
> 
> Cheers,
> Pete
>> 
>> This is program code, not library code. Having an error function that
>> prints the message and exits with 1 makes the code far simpler to
>> read. In particular it is easy to see that we always exit instead of
>> reading potential garbage when forgetting to check the return.
>> 
>> It is extremely uncommon to see broken .o files. Every single time I
>> have seen one is because I broke something in MC. In which case a
>> fatal error is also very helpful. It provides a convenient place to
>> put a breakpoint and see the entire context (stack) that found the
>> problem. With a fancy error handling you have to step down to see what
>> decided to return an error.
>> 
>> Cheers,
>> Rafael
>