[llvm-dev] .ARM.exidx woes

[Peter Smith via llvm-dev]

Hello Rob,

I'm not aware of any way to suppress the generation of the .ARM.exidx
section with clang. There is some rationale behind this decision as
having a 'cantunwind' makes it possible to mix such code with code
that uses exceptions and still allow exceptions to propagate through
the subset of the program that has been compiled with exceptions. A
linker should be able to compress all the sections down to a single
entry perhaps with a terminating sentinel so it shouldn't be larger
than 16 bytes. I appreciate that in an embedded system every last byte
counts though.

In LLD we do support discarding the .ARM.exidx, LLD has a --reproduce
option that you could use to file a PR, I'd be happy to take a look at
it. I'd expect /DISCARD/ : { *(.ARM.exidx) *(.ARM.exidx*)
*(.gnu.linkonce.armexidx.*) } to work. LLD hasn't had a lot of
exposure in embedded systems yet, if you do encounter problems please
do raise PRs as we often need real use cases to help guide the
implementation.

Peter

On Fri, 1 Mar 2019 at 07:39, Rob via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Is it possible to force llvm/clang to not create a .ARM.exidx section for a bare-metal application that does not use exceptions?  I've tried -fno-exceptions -fno-unwind-tables, but it still generates the section with all functions marked as 'cantunwind'.  As a temporary punt I tried linking (using lld) with /DISCARD/ on the section, but that seemed to crash lld, which is another problem for another day.  Any suggestions?
>
> RRM
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev