[llvm-dev] .ARM.exidx woes

[Rob via llvm-dev]

Appreciate the response - explanation makes sense. It might be desirable to
have something like '-fno-exceptions -fno-unwind-tables' really kill that
section but I won't push that argument.

As to the lld issue, I was seeing a crash in 6.0.1.  This was specifically
just using: "/DISCARD/ : { *(.ARM.exidx*) }".  I tried this morning with
7.0.0 and it did not reproduce, so call it fixed?  If you want me to post a
reproducible case for 6.0.1, I can.

Thanks again,
RRM

On Fri, Mar 1, 2019 at 5:13 AM Peter Smith <peter.smith at linaro.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190301/b63fdf45/attachment-0001.html>