[llvm-dev] Resurrect Bug18710 (Only generate .ARM.exidx and ARM.extab when needed with EHABI)

[Tanya Lattner via llvm-dev]

> On Mar 24, 2017, at 3:14 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> 
> On Mar 21, 2017 4:26 AM, "Christian Bruel via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello Everyone,
> 
> This is my first attempt to getting used with the submission process. Trying to get the "good practice" with the coding standard, tools, mailing lists... and already a few questions:
> 
> - Is it possible to "link" 2 related entries in Phabricator ? one for LLVM and one for CFE ? what's the best way of posting 2 related or dependent patches ? 
> 
> Often you can just link it in the description. I think Phab will even auto-connect them if you say somethig like "Depends on D12345". If you look at some of chandlerc's pass manager patches on Phab I know he was using Phab's dependency feature for some of them.
> 
> 
> - I'd like to update and follow on the discussion on bugzilla tracker that Renato created already but I can't edit (account requested to llvm-admin at lists.llvm.org <mailto:llvm-admin at lists.llvm.org> without luck). Could someone help ?
> 
> Tanya, Anton? Could one of you help with the bugzilla account?

Has an account. Needs to reset password.

-Tanya

> 
> -- Sean Silva
> 
> So now the proposal:
> 
> The .exidx and .extab unwind sections are needed, when exceptions are enabled, for unwinding if the function can throw and to hold the EXIDX_CANTUNWIND value if the function does not throw.
> 
> The problem was already discussed in various threads and defects, so I won't repeat  the details but basically that confusion is that if the compiler (or the user) determined that the function cannot throw, we have the NOUNWIND attribute which is not orthogonal with either exception support. Despite this we should still emit the unwind entry for the EXIDX_CANTUNWIND value, which is always done.
> Another issue is that canThrow (!NoUnwind) is set by default. Setting NoUnwind is an optimisation which is not handled by the ARM Streamer. A first approach was to have the backend return needsUnwindTableEntry() false if noexception support, but unwind tables can be used without exception handler (e.g) for debug infos or C unwind with attribute cleanup, and this happened to be quite intrusive...
> But simpler, when the exceptions are not enabled, we should be able to remove them. Just passing this this bit of information through a new disable-arm-cantunwind llvm option makes the uwtable and nounwind table orthogonal with exception support. 
> This option is set in clang when no exception support allowing to have the -f[no-]exceptions and -f[no-]unwind-tables match GCC for C and C++.
> 
> Thanks a lot for your feedbacks, questions and hints for getting on board !
> https://reviews.llvm.org/D31139 <https://reviews.llvm.org/D31140>
> https://reviews.llvm.org/D31140 <https://reviews.llvm.org/D31140>
> 
> 
> Christian
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170324/f28f0cd4/attachment.html>