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

[Sean Silva via llvm-dev]

On Mar 21, 2017 4:26 AM, "Christian Bruel via llvm-dev" <
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 without luck). Could someone help ?

Tanya, Anton? Could one of you help with the bugzilla account?

-- 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

 Christian





_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
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/0753a4d7/attachment.html>