[LLVMdev] [cfe-dev] Unwind behaviour in Clang/LLVM

[Logan Chien]

Hi Evgeniy,

I have run in to the some unwind handling table issue recently.  After some
investigation, I believe that the correct behavior is to generate
[cantunwind] with and without the -funwind-tables.  Thus, I am afraid that
-funwind-tables might not be a good solution for your use case.  (i.e. your
program might fall in an infinite loop during stack unwinding.)

I will send the details for discussion ASAP.

Sincerely,
Logan


On Thu, Feb 13, 2014 at 10:03 PM, Evgeniy Stepanov <eugenis at google.com>wrote:

> On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
> > On 13 February 2014 13:47, Evgeniy Stepanov <eugenis at google.com> wrote:
> >> Hm, I see that -funwind-tables on arm-linux-androideabi target
> >> replaces this "cantunwind" with a proper unwind table.
> >> Hence http://llvm-reviews.chandlerc.com/D2762.
> >
> > If Android is using EHABI (I think it is), the default now is to
> > output full tables all the time, everywhere. This will change to be
> > the same as x86 soon.
>
> It does use EHABI, but at r201326:
> $ cat 1.cc
> int f() {}
> $ ./bin/clang++ -target arm-linux-androideabi 1.cc -c
> $ readelf -u 1.o
> 0x0 <_Z1fv>: 0x1 [cantunwind]
> $ ./bin/clang++ -target arm-linux-androideabi 1.cc -c -funwind-tables
> $ readelf -u 1.o
> 0x0 <_Z1fv>: 0x8000b0b0
>   Compact model 0
>   0x00      vsp = vsp + 4
>   0xb0      finish
>   0xb0      finish
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140215/3f9170f4/attachment.html>