The _Unwind_Backtrace code for arm based systems is non-functional.

[llvmbot]

Bugzilla Link	20779
Resolution	FIXED
Resolved on	Aug 29, 2014 12:10
Version	unspecified
OS	other
Attachments	Example of failing test.
Reporter	LLVM Bugzilla Contributor
CC	@mclow

Extended Description

src/Unwind/UnwindLevel1-gcc-ext.c implements the _Unwind_Backtrace function. Arm has it's own unwind format that is special, and on this platform, the IP is never modified. Calling this function results in an infinite loop calling the trace function without ever terminating.

Attached is a simple example that will run infinitely.

I implemented a hack to allow this to work. Adding this to the end of _Unwind_Backtrace

#if LIBCXXABI_ARM_EHABI
// Get the information for this frame.
unw_proc_info_t frameInfo;
if (unw_get_proc_info(&cursor, &frameInfo) != UNW_ESUCCESS) {
return _URC_END_OF_STACK;
}

uint32_t* unwindInfo = (uint32_t *) frameInfo.unwind_info;
uint32_t format = ((*unwindInfo & 0x0f000000) >> 24);
size_t len, startOffset;
switch (format) {
  case 0:  // Short descriptor, 16-bit entries
    len = 4;
    startOffset = 1;
    break;
  case 1:  // Long descriptor, 16-bit entries
  case 3:  // Long descriptor, 32-bit entries
    len = 4 + 4 * ((*unwindInfo & 0x00ff0000) >> 16);
    startOffset = 2;
    break;
  default:
    startOffset = 0;
    break;
}
// Update the IP address.
result = _Unwind_VRS_Interpret((struct _Unwind_Context *)(&cursor),
    unwindInfo, startOffset, len);
if (result != _URC_CONTINUE_UNWIND) {
  return _URC_END_OF_STACK;
}

#endif // LIBCXXABI_ARM_EHABI

This is just a kludge to allow this code to work to mostly work. It also has a problem since the backtrace will stop at the first catch it finds even with this code.

This can be tested on an Android aosp tree if necessary.

[llvmbot]

Found the cause of not finishing the unwind. We're failing this assertion: https://github.com/llvm-mirror/libcxxabi/blob/master/src/Unwind/Unwind-EHABI.cpp#L171

[llvmbot]

Christopher,

Can you attach the output of running readelf -u, and step a debugger to the location where Dan says the assertion fails, then print out several things. Normally what I'd do here in gdb is: 'p/x *ucbp', 'p/x unwindingData', 'p/x *unwindingData', 'info symbol unwindingData'. That should help with diagnosing this.

Cheers,
Jon

[llvmbot]

readelf -u dump of test program

[llvmbot]

It's not exactly that assertion (since cferris's code doesn't take that path). I pulled out the part of the code responsible for interpreting the information so it could be shared between _Unwind_Backtrace() and unwindOneFrame().

So, more accurately, we're failing this assertion: https://github.com/DanAlbert/libcxxabi/blob/backtrace/src/Unwind/Unwind-EHABI.cpp#L212

readelf output of back_check and libc++abi is attached. Will also attach the test program and Android.mk.

In this context, there is no ucbp (we're called from _Unwind_Backtrace). Also, info symbol seems to not work with Android. It's more likely that there's just some Android gdb voodoo I don't know about, so I'll try to post that information one people start showing up for the day. The values of unwindingData (here unwindInfo) and *unwindingData (here data) are below.

#​8 0xb6f008e2 in _Unwind_Backtrace (callback=0xb6efc5a9 <trace_function(_Unwind_Context*, void*)>, ref=0x0) at external/libcxxabi/src/Unwind/UnwindLevel1-gcc-ext.c:156
156 result = interpret_unwind_data(*unwindInfo, &off, &len);
(gdb) p/x unwindInfo
$1 = 0xb6f2e05c
(gdb) down
#​7 0xb6efedd6 in interpret_unwind_data (data=2147283741, off=0xbeeaf1d4, len=0xbeeaf1d0) at external/libcxxabi/src/Unwind/Unwind-EHABI.cpp:212
212 assert((data & 0xf0000000) == 0x80000000 && "Must be a compact entry");
(gdb) p/x data
$2 = 0x7ffcf31d

[llvmbot]

readelf -u dump of libc++abi.a

[llvmbot]

Android.mk for test program

[llvmbot]

Test program

[llvmbot]

Fixed by http://reviews.llvm.org/D5112.