llvm dev - Mar 2019 - .ARM.exidx woes

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>

Hello,

Thanks for the update. I can reproduce a crash with LLD 6.0.0 with the
trunk LLD test case so I think it is likely that the problem has only
recently been fixed. I don't think that there will be a 6.0.2 release
so I'm happy to leave it that.

Peter


On Fri, 1 Mar 2019 at 13:20, Rob <rrmills at gmail.com>
wrote:
>
> 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