On 3/21/17 1:53 PM, Christian Bruel via Phabricator wrote:
chrib added a comment.
In https://reviews.llvm.org/D31140#706411, @jroelofs wrote:
Can you clarify the logic here? It's my understanding that:
`-fno-exceptions` does *not* imply `-fno-unwind-tables`
however:
`-fno-unwind-tables` *does* imply that exceptions cannot be used on targets
that require the tables to do unwinding.
Yes, (bad things might happen or (std::terminate will be called, or destructors
not called.)...
But -f[no]-unwind-tables implies the UWTable attribute, not NoUwind attribute.
To toggle NoUnwind, use -fno-exceptions
And this is getting worse with .canunwind which means DoesNotThrow :)
in my understanding, the logic is as follow:
Since "An exception cannot propagate through a function with a nounwind table. The
exception handling runtime environment terminates the program if it encounters a nounwind
table during exception processing." (ARM Information Center)
The "nounwind" LLVM attribute, which means "Function does not throw" translates
as the EXIDX_CANTUNWIND value in the exception table index table which needs to be created for the
purpose (for the function)
I think the problem is here, actually. "nounwind" implies "does not
throw", but "does not throw" really should not imply "nounwind". This is
something that ought to be clarified in the langref with the addition of
a "does not throw" attribute. Then the optimizer should be fixed to
deduce "does not throw" instead of "nounwind", and we can let "nounwind"
continue to imply .cantunwind.
And of course without exception runtime environment (the test here) we don't
need this table. So I can see 3 cases:
- nounwind set : Generate .cantunwind directive and unwind
table
- nounwind set but not EH Do not generate the .cantunwind directive and do
not emit the unwind table
- uwtable set Need to generate the unwind table (even
without EH)
The disable-arm-cantunwind flag means: without EH support if the function does
not throw, do dot generate the exception tables and the EXIDX_CANTUNWIND value.
I'm not a big fan of this workaround flag. I'd rather see this fixed by
clarifying/fixing the semantics of the IR.
Jon
https://reviews.llvm.org/D31140
--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
