llvm dev - Feb 2019 - .ARM.exidx woes

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

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

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>

Hi Rob,

lld has improved significantly in recent years. Version 6.0 was a bit too
old, as the most recent release is 7.0.1 and we are about to release lld
8.0. You may see not only a fix for the issue you mentioned but also other
improvements in more recent versions. I'd update the linker.

On Thu, Feb 28, 2019 at 11:39 PM 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/33d86d70/attachment.html>