[lld] r258499 - Use of llvm_unreachable instead of warning in EhFrameHeader<ELFT>::assignEhFrame().

[David Blaikie via llvm-commits]

On Fri, Jan 22, 2016 at 8:57 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >On Fri, Jan 22, 2016 at 8:27 AM, George Rimar <grimar at accesssoftek.com>
> wrote:
>
>> >>This should probably be written with an assert instead:
>> >>
>> > > assert((!this->Sec || this->Sec == Sec) && "multiple .eh_frame
>> sections ....");
>> >
>> > This should never happen, and if will due to a bug or something then
>> result is completely unknown, because
>> > code does not suppose that. So it is fatal error actually.
>>
> >
> >If it's never meant to happen (if it does happen, it's a programmer
> error) then that's entirely appropriate for an assertion.
> >
>
>> > That why I think unreachable fits better than assert and also there is
>> no asserts in release usually.
>>
> >
> > That's correct - assertions are used to test for programmatic
> errors/mistakes.
> >
> > unreachable is roughly equivalent - if not worse, with unreachable, in
> an -O0 build the unreachable behaves something like an assert (the program
> will fail hard, print an error, > etc) but in anything else, LLVM will
> optimize assuming the condition is true. This means if the condition is not
> true, the behavior may be worse than just continuing without > having done
> anything. LLVM will deduce that the condition /must/ be true.
> >
> > - Dave
>
> So If we have unreachable it will work as assert for us here for all cases
> except release with optimizations. Then if we realy want to be safe then
> its probably better to call error() here to cover everything. I dont think
> that assert is better in case of -Ox because code just does not support
> that case, it can crash or hang or whatever, I dont know what will be and
> assert is not better for "final" release here because will be just skipped.
>

I think we're talking past each other a bit, and I'm not quite sure how to
resolve the disconnect here, but I'll try.

The general idea is that code shouldn't be written to be resilient to
programmer errors - once invariants and preconditions have been violated,
there's really nothing we can do anyway. Also, we don't want to spend time
checking all these invariants and preconditions in release builds (because
we want the compiler to be fast). So we use assertions and unreachable,
rather than conditionals and error handling/reporting for cases that are
not intended to be possible. (
http://llvm.org/docs/CodingStandards.html#assert-liberally discusses some
of this)

In short, if this case is only reachable by a programmer error, it should
be an assert. (unreachable is used when it's a block of code that can't be
reached - like a default in a switch, the end of a function that has some
algorithmic reason to always return through some other path, etc - this is
discussed in the coding standard linked above)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160122/7d3574f8/attachment.html>