<div dir="ltr">Thank Dan for pointing out Android is moving to its own unwinder soon, so maybe the problem will be missing in Android P.<div><br></div><div>Dan, when I investigate this problem, I find prebuilts/ndk sources/cxx libc++ for Android 5.0/6.0/7.0 is built with libcxx + gabi++.</div><div>It it strange that Android 5.0 prebuilts/ndk libc++ works but Android 6.0 fails from <a href="https://android.googlesource.com/platform/prebuilts/ndk/+/45b1d17d3c24e23b0955928e62881e6fd0f7b8c5">https://android.googlesource.com/platform/prebuilts/ndk/+/45b1d17d3c24e23b0955928e62881e6fd0f7b8c5</a>.</div><div>Is it a way that I can rebuilt this commit to test why it fails?</div><div><br></div><div>Can anyone give me some suggestion why UnwindCursor sounds to align to 8 for ARM EHABI? I just find <a href="http://link.zhihu.com/?target=https%3A//wiki.debian.org/ArmEabiPort%23Struct_packing_and_alignment">ArmEabiPort - Debian Wiki</a> but it does not tell anything about C++ vptr. </div><div><br></div><div>Thanks,</div><div>Jean.<br><div class="gmail_extra"><br><div class="gmail_quote">2018-03-02 3:13 GMT+08:00 Dan Albert <span dir="ltr"><<a href="mailto:danalbert@google.com" target="_blank">danalbert@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">FWIW Android is moving to its own unwinder soon (<a href="https://android.googlesource.com/platform/system/core/+/master/libunwindstack/" target="_blank">https://android.googlesource.<wbr>com/platform/system/core/+/<wbr>master/libunwindstack/</a>) and the NDK is removing all STLs but libc++ (and thus NDK apps won't use libgcc for unwinding any more) in NDK r18.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Wed, Feb 28, 2018 at 8:39 PM, Jean Lee via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr">If mixing libunwind with other personality function like libgcc_s<div>First, we use <span style="color:rgb(0,0,0);font-family:monospace;white-space:pre-wrap">_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND in _Unwind_Backtrace() which calls continue_unwind(), so why not call _US_UNWIND_FRAME_RESUME? It calls continue_unwind() too. </span><a href="https://llvm.org/viewvc/llvm-project/libunwind/trunk/src/UnwindLevel1-gcc-ext.c?view=markup" target="_blank">https://llvm.org/viewvc/llvm-p<wbr>roject/libunwind/trunk/src/Unw<wbr>indLevel1-gcc-ext.c?view=marku<wbr>p</a></div><div>Second, _Unwind_Context is not compatible.<br><div>To make _Unwind_Context binary compatible in core registers with <span style="font-size:14px">phase1_vrs in libgcc_s, we should:</span></div><div><span style="font-size:14px">(1) Swap _registers and _addressSpace in UnwindCursor class.</span></div><div><span style="font-size:14px">(2) Make UnwindCursor aligned to 4 for ARM EHABI. </span></div><div><span style="font-size:14px"><b>I don't know why the first member of UnwindCursor align to 8 for ARM EHABI. UnwindCursor implements the interface class AbstractUnwindCursor.</b></span></div><div><br></div><div><span style="font-size:14px">To conclude,</span></div><div><span style="font-size:14px">1. Mixing libunwind _Unwind_Backtrace with other personality function will lead to incompatible behavior. I suggest we call continue_unwinding() than call personality function.</span></div><div><span style="font-size:14px">2. Though we could change UnwindCursor to make it compatible with libgcc_s in some case and even use </span><span style="color:rgb(0,0,0);font-family:monospace;white-space:pre-wrap">_US_UNWIND_FRAME_RESUME to make it compatible with gabi++</span><span style="font-size:14px">, it is not a good method.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Regards,</span></div><div><span style="font-size:14px">Jean</span></div><div><div class="gmail-m_5730308949094491500h5"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-27 23:06 GMT+08:00 Jean Lee <span dir="ltr"><<a href="mailto:xiaoyur347@gmail.com" target="_blank">xiaoyur347@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Background:</div>Android has an malloc debug function which described in <a href="https://android.googlesource.com/platform/bionic/+/master/libc/malloc_debug/" target="_blank">https://android.googlesourc<wbr>e.com/platform/bionic/+/master<wbr>/libc/malloc_debug/</a>. When it is enabled, it use libunwind _Unwind_Backtrace to record malloc stacktrace and can analyze memory problems such as memory leaks.<div>Condition 1:<br><div>It works from Android 5.0 with libunwind(still in libcxxabi) commit <a href="https://llvm.org/viewvc/llvm-project?view=revision&revision=216730" target="_blank">https://llvm.org/viewvc<wbr>/llvm-project?view=revision&re<wbr>vision=216730</a>.</div><div>This commit avoids call personality function likes __gxx_personality_v0 but with &__gxx_personality_v0 which means only in static build it can continue unwinding.</div></div><div><br></div><div>Condition 2:</div><div>Android 6.0 pick up libunwind(still in libcxxabi) commit <a href="https://llvm.org/viewvc/llvm-project?view=revision&revision=226822" target="_blank">https://llvm.org/viewvc<wbr>/llvm-project?view=revision&re<wbr>vision=226822</a>.</div><div>This commit try to fix Condition 1 by call personality function in Generic Model.</div><div>And it leads to the problem I will describe later.</div><div><br></div><div>Condition 3:</div><div>Android 7.0 comes with libunwind move out from libcxxabi and pick up libunwind commit <a href="https://llvm.org/viewvc/llvm-project?view=revision&revision=238560" target="_blank">https://llvm.org/viewvc<wbr>/llvm-project?view=revision&re<wbr>vision=238560</a>.</div><div>This commit do further more and only calls personality function in _Unwind_Backtrace. To use this commit, libcxxabi should pick up commit <a href="https://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_personality.cpp?r1=238561&r2=238560&pathrev=238561" target="_blank">https://llvm.org/viewvc<wbr>/llvm-project/libcxxabi/trunk/<wbr>src/cxa_personality.cpp?r1=238<wbr>561&r2=238560&pathrev=238561</a>.</div><div><br></div><div>Problem in ARM EHABI likes armv7a:</div><div>When using malloc debug in Android, it means the application loads libc_malloc_debug first, and it is compiled with libunwind(llvm). And my application still use gnustl static or shared which means libgcc_s.a is used for user application.</div><div>And when the application calls malloc, it will go into libc_malloc_debug and call libunwind _Unwind_Backtrace() and _Unwind_Backtrace() will call personality function. In Android 6.0, it calls libgcc_s personality function in <a href="https://android.googlesource.com/toolchain/gcc/+/ndk-r15-release/gcc-4.9/libstdc++-v3/libsupc++/eh_personality.cc" target="_blank">https://android.googlesourc<wbr>e.com/toolchain/gcc/+/ndk-r15-<wbr>release/gcc-4.9/libstdc++-v3/l<wbr>ibsupc++/eh_personality.cc</a>. And it dies with the backtrace as follows:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>02-25 21:42:28.269 F/DEBUG ( 285): pid: 12453, tid: 12453, name: mo.helloandroid >>> com.jean.demo.helloandroid <<<</div></div><div><div>02-25 21:42:28.269 F/DEBUG ( 285): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0</div></div><div><div>02-25 21:42:28.289 F/DEBUG ( 285): r0 00000001 r1 00004080 r2 00000000 r3 00000008</div></div><div><div>02-25 21:42:28.289 F/DEBUG ( 285): r4 00004080 r5 bea56a28 r6 00000080 r7 00000000</div></div><div><div>02-25 21:42:28.289 F/DEBUG ( 285): r8 bea564e4 r9 bea565a8 sl 80000000 fp 00000005</div></div><div><div>02-25 21:42:28.289 F/DEBUG ( 285): ip b39c61b8 sp bea563b8 lr b39d6955 pc b39d64bc cpsr 240d1c30</div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285):</div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285): backtrace:</div></div><div><div><br></div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285): #00 pc 000144bc /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (_Unwind_VRS_Pop+47)</div></div><div><div>/Volumes/Android/buildbot/src/<wbr>android/gcc/toolchain/build/..<wbr>/gcc/gcc-4.9/libgcc/config/arm<wbr>/unwind-arm.c:240</div></div><div><div><br></div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285): #01 pc 00014951 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (__gnu_unwind_execute+162)</div></div><div><div>/Volumes/Android/buildbot/src/<wbr>android/gcc/toolchain/build/..<wbr>/gcc/gcc-4.9/libgcc/config/arm<wbr>/pr-support.c:153</div></div><div><div><br></div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285): #02 pc 00014b45 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (__gnu_unwind_frame+32)</div></div><div><div>/Volumes/Android/buildbot/src/<wbr>android/gcc/toolchain/build/..<wbr>/gcc/gcc-4.9/libgcc/config/arm<wbr>/pr-support.c:331</div></div><div><div><br></div></div><div><div>02-25 21:42:28.300 F/DEBUG ( 285): #03 pc 00004599 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (__gxx_personality_v0+336)</div></div><div><div>/Volumes/Android/buildbot/src/<wbr>android/ndk-r15-release/toolch<wbr>ain/gcc/gcc-4.9/libstdc++-v3/l<wbr>ibsupc++/eh_personality.cc:386</div></div><div><div><br></div></div><div><div>02-25 21:42:28.301 F/DEBUG ( 285): #04 pc 00008517 /system/lib/libc_malloc_debug<wbr>_leak.so (_Unwind_Backtrace+130)</div></div><div><div>02-25 21:42:28.301 F/DEBUG ( 285): #05 pc 00006003 /system/lib/libc_malloc_debug<wbr>_leak.so (get_backtrace(unsigned int*, unsigned int)+34)</div></div><div><div>02-25 21:42:28.301 F/DEBUG ( 285): #06 pc 00006a7d /system/lib/libc_malloc_debug<wbr>_leak.so (leak_malloc+84)</div></div><div><div>02-25 21:42:28.301 F/DEBUG ( 285): #07 pc 00007911 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (operator new(unsigned int)+12)</div></div><div><div>02-25 21:42:28.301 F/DEBUG ( 285): #08 pc 00006eb1 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag)+144<wbr>)</div></div><div><div>02-25 21:42:28.302 F/DEBUG ( 285): #09 pc 000071e3 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)+30)</div></div><div><div>02-25 21:42:28.302 F/DEBUG ( 285): #10 pc 000041f3 /data/app/com.jean.demo.hello<wbr>android-1/lib/arm/libnative-li<wbr>b.so (Java_com_jean_demo_helloandro<wbr>id_MainActivity_stringFromJNI+<wbr>58)</div></div><div><div>02-25 21:42:28.302 F/DEBUG ( 285): #11 pc 008629e9 /data/app/com.jean.demo.hello<wbr>android-1/oat/arm/base.odex (offset 0x432000) (java.lang.String com.jean.demo.helloandroid.Mai<wbr>nActivity.stringFromJNI()+76)</div></div><div><div>02-25 21:42:28.302 F/DEBUG ( 285): #12 pc 008626f9 /data/app/com.jean.demo.hello<wbr>android-1/oat/arm/base.odex (offset 0x432000) (void com.jean.demo.helloandroid.Mai<wbr>nActivity.onCreate(android.os.<wbr>Bundle)+444)</div></div></blockquote><div><br></div><div>After some investigate to this problem, I find there are some problems here.</div><div>(1) <b>Is it designed to mix libunwind(llvm) with libgcc_s personality routine?</b> libgcc_s has compatible _Unwind_Control_Block with libunwind but has incompatible _Unwind_Context with libunwind.</div><div>In gcc, _Unwind_Context is</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">struct core_regs<br>{<br> _uw r[16];<br>};<br>/* We use normal integer types here to avoid the compiler generating<br> coprocessor instructions. */<br>struct vfp_regs<br>{<br> _uw64 d[16];<br> _uw pad;<br>};<br>struct vfpv3_regs<br>{<br> /* Always populated via VSTM, so no need for the "pad" field from<br> vfp_regs (which is used to store the format word for FSTMX). */<br> _uw64 d[16];<br>};<br>struct wmmxd_regs<br>{<br> _uw64 wd[16];<br>};<br>struct wmmxc_regs<br>{<br> _uw wc[4];<br>};<br>typedef struct<br>{<br> /* The first fields must be the same as a phase2_vrs. */<br> _uw demand_save_flags;<br> struct core_regs core;<br> _uw prev_sp; /* Only valid during forced unwinding. */<br> struct vfp_regs vfp;<br> struct vfpv3_regs vfp_regs_16_to_31;<br> struct wmmxd_regs wmmxd;<br> struct wmmxc_regs wmmxc;<br>} phase1_vrs;</blockquote></div><div>But in libunwind, it is a class with vptr UnwindCursor<LocalAddress<wbr>Space, Registers_arm>.</div><div><br></div><div>In <a href="https://android.googlesource.com/toolchain/gcc/+/ndk-r15-release/gcc-4.9/libgcc/config/arm/pr-support.c" target="_blank">https://android.googlesourc<wbr>e.com/toolchain/gcc/+/ndk-r15-<wbr>release/gcc-4.9/libgcc/config/<wbr>arm/pr-support.c</a>, it also calls</div><div>_Unwind_VRS_Set (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32,</div><div><span class="gmail-m_5730308949094491500m_-4942792552262912567gmail-m_-4295917725337934335gmail-Apple-tab-span" style="white-space:pre-wrap"> </span> ®);</div><div>to store context but what's the context here?</div><div><br></div><div>(2) Since I have no way because Android use libunwind and our application should still use gnustl for a while. It means the mix will long exists.</div><div>(3) Actually in Condition 1, it sounds it does not call personality function for Generic Model, but since it calls _Unwind_VRS_Interpret, it really does as libcxxabi __gxx_personality_v0 does!</div><div>So, I have a question, <b>can we inline libcxxabi __gxx_personality_v0 in _Unwind_Backtrace</b> to avoid external call to personality function like libgcc_s and old libcxx+gabi++, and it mays dies in some condition.</div><div>If it can, actually we should only pick up __gnu_unwind_frame() for personality function.</div><div><br></div><div>Regards.</div></div>
</blockquote></div><br></div></div></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div>