[cfe-dev] ARM Linux libc++ / libunwind — Exceptions not being caught

[Andrew Brownsword via cfe-dev]

I already checked ldd and the paths are as I expect... but I was surprised to see gcc_s in the list.  Is that expected?

It is only the std exceptions thrown from libc++ that seem to have a problem, so doesn’t that imply that the lib is internally inconsistent (which an include path problem couldn’t cause?).

> On Aug 30, 2018, at 2:11 PM, Louis Dionne <ldionne at apple.com> wrote:
> 
> 
>> On Aug 30, 2018, at 17:03, Andrew Brownsword <andrew.e.brownsword at gmail.com> wrote:
>> 
>> I followed these steps with a couple of caveats:
>>    * used the (mostly) working clang toolchain I have in place (7.0.0rc2)
>>    * removed the -mcpu options (don’t know what valid list is)
>>    * had to prefix sub-project names with llvm/projects/*
>>    * created build directory in llvm/ (don’t normally like to do that)
>>    * ninja unwind (no lib prefix)
>>    * also tried using install-* target; built test program with paths to build dir as well as to the installed locations
>> 
>> Still doesn’t catch the stoul exception.
>> 
> 
> I would suggest that you:
> 
> 1. Use ldd to see exactly what shared objects are loaded by your program, and confirm that those are the ones you expect.
> 2. Run `nm --demangle` on libc++, libc++abi, libunwind and your program and look for the typeinfo of your exception class.
> 3. When building libcxxabi and libunwind, pass `-v` to ninja to see all the compilation commands, and then modify a command to preprocess `-E` the file instead and see exactly which headers are used to build. Confirm that you’re building libc++abi and libunwind against the correct headers.
> 
> Maybe you’ll find out that the exception class has typeinfo in more than one place, which could lead to the exception not being caught (if it’s thrown with a typeinfo different from the one used to catch). I’ve debugged very similar problems like that in the past. Another option is that your libunwind/libc++abi are somehow built against different headers or in a different configuration than you’re expecting, and that can lead to trouble (we’ve had one like that during the LLVM 7 release).
> 
> Louis
> 
>> 
>>> My steps were:
>>> 1.) Build trunk clang to use for building libc++ etc.
>>> 2.) Using cmake
>>> 
>>> cmake -GNinja\
>>>    /path/to/monorepo/llvm \
>>>    -DLLVM_ENABLE_PROJECTS="libcxxabi;libcxx;libunwind" \
>>>    -DCMAKE_BUILD_TYPE=Release \
>>>    -DLLVM_ENABLE_ASSERTIONS=true\
>>>    -DCMAKE_C_FLAGS='-mcpu=cortex-a57'\
>>>    -DCMAKE_CXX_FLAGS='-mcpu=cortex-a57'\
>>>    -DLLVM_TARGETS_TO_BUILD='ARM'\
>>>    -DLIBCXXABI_USE_LLVM_UNWINDER=On
>>> 3.) build
>>> ninja libunwind
>>> ninja cxxabi
>>> ninja cxx
>>> 
>>> I was then able to run the example with:
>>> clang++ --stdlib=libc++ -I ./include/c++/v1 t.cpp -o t.axf -L ./lib -v
>>> --std=c++17
>>> LD_LIBRARY_PATH=lib ./t.axf./t.axf
>>> caught!
>> 
>