[cfe-dev] libcxxabi cmake test problem on Linux x86-64
Ismail Donmez via cfe-dev
cfe-dev at lists.llvm.org
Wed Dec 16 09:31:00 PST 2015
Hi,
This bootstraps cleanly on openSUSE Linux, thanks for fixing this.
ismail
On Tue, Dec 15, 2015 at 12:40 AM, Eric Fiselier via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> This should be fixed in r255559 and r255560.
>
> @Ismail Please let me know if this broke something for you. I think I got
> the library order I needed but I'm not 100% sure.
>
> @Chandlerc The bootstrap should be clean now.
>
> /Eric
>
>
> On Thu, Dec 10, 2015 at 8:50 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>
>> Alright, so the problem is that libgcc_eh.a marks most of the _Unwind
>> symbols as hidden. This means that when libgcc_eh.a is linked into a shared
>> library exceptions cannot be thrown beyond the library boundary. I think
>> that both libgcc_s and libgcc_eh were being linked into lli causing the
>> failures. Since we typically build libc++abi as a shared library we need to
>> use libgcc_s.so instead. (I think we will still need to use libgcc_eh when
>> creating a static libc++abi)
>>
>> I think that libc++abi should link the default libraries exactly as clang
>> would if we didn't specify '-nodefaultlibs`. This resulting link line for
>> libc++abi.so should look something like:
>>
>> -lm -lgcc_s -lpthread -lc -lgcc_s
>>
>> The resulting libc++abi.so will still have undefined references to
>> libgcc.a's _Unwind symbols but libgcc.a should always be linked into the
>> final executable.
>> When using and testing libc++abi (via libc++) the link line should look
>> something like:
>>
>> -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc
>>
>> When we want to use llvm's unwinder we will probably need to use -lunwind
>> -lcompiler-rt instead but I'm not too familiar with this configuration.
>>
>> I'll put a patch together tonight.
>>
>> /Eric
>>
>> On Thu, Dec 10, 2015 at 6:26 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>>
>>> I've spent most of today looking into this and I still have no clue
>>> what's going on. I think I need to know more about how lli provides libc++.
>>>
>>> I was able to reproduce the bug using the following steps:
>>>
>>> 1. export CC=clang CXX=clang++
>>> 2. cmake --DLLVM_ENABLE_LIBCXX=ON -DLLVM_BUILD_PROJECTS=OFF../llvm
>>> 3. ./bin/lli llvm/test/ExecutionEngine/MCJIT/eh.ll
>>>
>>> The above steps assume that you already have libc++.so installed
>>> somewhere the linker can find it
>>> and that libc++.so is a linker script that includes -lc++abi.
>>>
>>> I turned LLVM_BUILD_PROJECTS off so that we aren't contending with two
>>> different libc++abi binaries.
>>>
>>> Any help with this bug would be appreciated.
>>>
>>> /Eric
>>>
>>> On Wed, Dec 9, 2015 at 12:27 PM, Chandler Carruth <chandlerc at google.com>
>>> wrote:
>>>>
>>>> Yep.
>>>>
>>>> On Wed, Dec 9, 2015 at 8:21 PM Eric Fiselier <eric at efcs.ca> wrote:
>>>>>
>>>>> I don't remember what's going on here but alot has changed in a year. I
>>>>> should be able to look into it later today.
>>>>>
>>>>> Chandler, I'm assuming your still able to reproduce the issue?
>>>>>
>>>>> /Eric
>>>>>
>>>>> On Wed, Dec 9, 2015 at 3:06 AM, Chandler Carruth <chandlerc at google.com>
>>>>> wrote:
>>>>>>
>>>>>> (Moving to the new mailing list)
>>>>>>
>>>>>> On Wed, Nov 26, 2014 at 10:09 PM Evgeniy Stepanov
>>>>>> <eugeni.stepanov at gmail.com> wrote:
>>>>>>>
>>>>>>> #0 0x00007ffff62b5bb9 in __GI_raise (sig=sig at entry=6) at
>>>>>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>>>>>> #1 0x00007ffff62b8fc8 in __GI_abort () at abort.c:89
>>>>>>> #2 0x00007ffff7b60807 in abort_message (format=0x7ffff7bcdf13
>>>>>>> "terminating with %s exception of type %s") at
>>>>>>> ../projects/libcxxabi/src/abort_message.cpp:66
>>>>>>> #3 0x00007ffff7b60ad6 in default_terminate_handler () at
>>>>>>> ../projects/libcxxabi/src/cxa_default_handlers.cpp:68
>>>>>>> #4 0x00007ffff7bc454e in std::__terminate (func=0x7ffff7b60900
>>>>>>> <default_terminate_handler()>) at
>>>>>>> ../projects/libcxxabi/src/cxa_handlers.cpp:68
>>>>>>> #5 0x00007ffff7bc31dd in __cxxabiv1::failed_throw
>>>>>>> (exception_header=0x1e87240) at
>>>>>>> ../projects/libcxxabi/src/cxa_exception.cpp:149
>>>>>>> #6 0x00007ffff7bc3136 in __cxa_throw (thrown_object=0x1e872b8,
>>>>>>> tinfo=0x7ffff7dd83b0 <typeinfo for int>, dest=0x0) at
>>>>>>> ../projects/libcxxabi/src/cxa_exception.cpp:244
>>>>>>> #7 0x00007ffff7ff502d in throwException ()
>>>>>>> #8 0x00007ffff7ff503d in main ()
>>>>>>> #9 0x0000000000beef04 in llvm::MCJIT::runFunction (this=0x1e74c30,
>>>>>>> F=0x1e6b4b0, ArgValues=...) at
>>>>>>> ../lib/ExecutionEngine/MCJIT/MCJIT.cpp:500
>>>>>>> #10 0x0000000000b26f90 in llvm::ExecutionEngine::runFunctionAsMain
>>>>>>> (this=0x1e74c30, Fn=0x1e6b4b0, argv=..., envp=0x7fffffffe0d0)
>>>>>>> at ../lib/ExecutionEngine/ExecutionEngine.cpp:393
>>>>>>> #11 0x0000000000567cc4 in main (argc=4, argv=0x7fffffffe0a8,
>>>>>>> envp=0x7fffffffe0d0) at ../tools/lli/lli.cpp:613
>>>>>>
>>>>>>
>>>>>> Any update here Eric? Or others? Would really like to get the
>>>>>> bootstrap clean with libc++abi.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 26, 2014 at 11:37 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>>>>>> > Evgeniy,
>>>>>>> >
>>>>>>> > Would you be willing to reproduce this again but in debug mode
>>>>>>> > instead
>>>>>>> > of release so we get a better stack trace?
>>>>>>> >
>>>>>>> > /Eric
>>>>>>> >
>>>>>>> > On Wed, Nov 26, 2014 at 5:20 AM, Evgeniy Stepanov
>>>>>>> > <eugeni.stepanov at gmail.com> wrote:
>>>>>>> >> I've got the same issue.
>>>>>>> >> On Linux (Trusty/x86_64), build clang with libc++/libc++abi (just
>>>>>>> >> plain ninja clang cxx cxxabi w/o any special cmake flags), then
>>>>>>> >> use it
>>>>>>> >> to bootstrap clang like this:
>>>>>>> >>
>>>>>>> >> CC=/code/llvm/build2/bin/clang \
>>>>>>> >> CXX=/code/llvm/build2/bin/clang++ \
>>>>>>> >> LDFLAGS="-lc++abi -L/code/llvm/build2/lib
>>>>>>> >> -Wl,-rpath,/code/llvm/build2/lib" \
>>>>>>> >> cmake \
>>>>>>> >> -GNinja \
>>>>>>> >> -DCMAKE_BUILD_TYPE=Release \
>>>>>>> >> -DLLVM_ENABLE_LIBCXX=ON \
>>>>>>> >> ..
>>>>>>> >>
>>>>>>> >> In the second tree, MCJIT tests fail with the same error:
>>>>>>> >>
>>>>>>> >> ./bin/lli -relocation-model=pic -code-model=large
>>>>>>> >> ../test/ExecutionEngine/MCJIT/eh-lg-pic.ll
>>>>>>> >> terminating with uncaught exception of type int
>>>>>>> >> 0 lli 0x0000000000a80a9a
>>>>>>> >> _ZN4llvm3sys15PrintStackTraceEP8_IO_FILE + 42
>>>>>>> >> 1 lli 0x0000000000a81eeb
>>>>>>> >> 2 libpthread.so.0 0x00007f83baabf340
>>>>>>> >> 3 libc.so.6 0x00007f83b9d2fbb9 gsignal + 57
>>>>>>> >> 4 libc.so.6 0x00007f83b9d32fc8 abort + 328
>>>>>>> >> 5 libc++abi.so.1 0x00007f83bb5121a7
>>>>>>> >> 6 libc++abi.so.1 0x00007f83bb512355
>>>>>>> >> 7 libc++abi.so.1 0x00007f83bb55c3b3
>>>>>>> >> 8 libc++abi.so.1 0x00007f83bb55bb66 __cxa_throw + 166
>>>>>>> >> 9 libc++abi.so.1 0x00007f83bb98802d __cxa_throw + 4375917
>>>>>>> >> 10 libc++abi.so.1 0x00007f83bb98803d __cxa_throw + 4375933
>>>>>>> >> 11 lli 0x0000000000849649
>>>>>>> >>
>>>>>>> >> _ZN4llvm5MCJIT11runFunctionEPNS_8FunctionERKNSt3__16vectorINS_12GenericValueENS3_9allocatorIS5_EEEE
>>>>>>> >> + 1209
>>>>>>> >> 12 lli 0x00000000007ecd08
>>>>>>> >>
>>>>>>> >> _ZN4llvm15ExecutionEngine17runFunctionAsMainEPNS_8FunctionERKNSt3__16vectorINS3_12basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEENS8_ISA_EEEEPKPKc
>>>>>>> >> + 1192
>>>>>>> >> 13 lli 0x000000000050c434 main + 10404
>>>>>>> >> 14 libc.so.6 0x00007f83b9d1aec5 __libc_start_main + 245
>>>>>>> >> 15 lli 0x00000000005092fb
>>>>>>> >> Stack dump:
>>>>>>> >> 0. Program arguments: ./bin/lli -relocation-model=pic
>>>>>>> >> -code-model=large ../test/ExecutionEngine/MCJIT/eh-lg-pic.ll
>>>>>>> >> Aborted (core dumped)
>>>>>>> >>
>>>>>>> >> On Sat, Aug 16, 2014 at 9:24 AM, İsmail Dönmez <ismail at donmez.ws>
>>>>>>> >> wrote:
>>>>>>> >>> Ping?
>>>>>>> >>>
>>>>>>> >>> On Jul 17, 2014 11:05 AM, "İsmail Dönmez" <ismail at donmez.ws>
>>>>>>> >>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Hi,
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> On Wed, Jul 16, 2014 at 6:43 PM, Nico Weber
>>>>>>> >>>> <thakis at chromium.org> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> On Wed, Jul 16, 2014 at 4:10 AM, İsmail Dönmez
>>>>>>> >>>>> <ismail at donmez.ws> wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> Hi,
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>> On Mon, Jul 14, 2014 at 8:10 PM, Dan Albert
>>>>>>> >>>>>> <danalbert at google.com>
>>>>>>> >>>>>> wrote:
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> Submitted (with some slight modifications,
>>>>>>> >>>>>>> s/libgcc_s/libgcc_eh/) as
>>>>>>> >>>>>>> r212958. Tested with and without the LLVM unwinder, and
>>>>>>> >>>>>>> things look good.
>>>>>>> >>>>>>> Thanks again!
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>> Changing gcc_s with gcc_eh doesn't look good. libcxxabi tests
>>>>>>> >>>>>> pass but
>>>>>>> >>>>>> llvm MCJIT exception tests fail with:
>>>>>>> >>>>>>
>>>>>>> >>>>>> "terminating with uncaught exception of type int"
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> Can you try to make a reduced test case for libcxxabi from
>>>>>>> >>>>> this?
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> Smallest test cases are
>>>>>>> >>>> test/ExecutionEngine/MCJIT/{eh-sm-pic,eh-lg-pic}.ll
>>>>>>> >>>>
>>>>>>> >>>> Both fail the same way:
>>>>>>> >>>>
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli -use-mcjit
>>>>>>> >>>> -relocation-model=pic -code-model=small
>>>>>>> >>>>
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll
>>>>>>> >>>> --
>>>>>>> >>>> Exit Code: 134
>>>>>>> >>>>
>>>>>>> >>>> Command Output (stderr):
>>>>>>> >>>> --
>>>>>>> >>>> terminating with uncaught exception of type int
>>>>>>> >>>> 0 libLLVMSupport.so 0x00007f9c6ddf7d85
>>>>>>> >>>> llvm::sys::PrintStackTrace(_IO_FILE*) + 37
>>>>>>> >>>> 1 libLLVMSupport.so 0x00007f9c6ddf83f3
>>>>>>> >>>> 2 libpthread.so.0 0x00007f9c6d0d79f0
>>>>>>> >>>> 3 libc.so.6 0x00007f9c6c806849 gsignal + 57
>>>>>>> >>>> 4 libc.so.6 0x00007f9c6c807cd8 abort + 328
>>>>>>> >>>> 5 libc++abi.so.1 0x00007f9c6cb89237
>>>>>>> >>>> 6 libc++abi.so.1 0x00007f9c6cb894b6
>>>>>>> >>>> 7 libc++abi.so.1 0x00007f9c6cbeda7e
>>>>>>> >>>> 8 libc++abi.so.1 0x00007f9c6cbec6ed
>>>>>>> >>>> 9 libc++abi.so.1 0x00007f9c6cbec646
>>>>>>> >>>> 10 libc++abi.so.1 0x00007f9c6ff3001c
>>>>>>> >>>> 11 libc++abi.so.1 0x00007f9c6ff30026
>>>>>>> >>>> 12 libLLVMMCJIT.so 0x00007f9c6e61fd27
>>>>>>> >>>> llvm::MCJIT::runFunction(llvm::Function*,
>>>>>>> >>>> std::__1::vector<llvm::GenericValue,
>>>>>>> >>>> std::__1::allocator<llvm::GenericValue>
>>>>>>> >>>> > const&) + 919
>>>>>>> >>>> 13 libLLVMExecutionEngine.so 0x00007f9c6f34fa65
>>>>>>> >>>> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
>>>>>>> >>>> std::__1::vector<std::__1::basic_string<char,
>>>>>>> >>>> std::__1::char_traits<char>,
>>>>>>> >>>> std::__1::allocator<char> >,
>>>>>>> >>>> std::__1::allocator<std::__1::basic_string<char,
>>>>>>> >>>> std::__1::char_traits<char>, std::__1::allocator<char> > > >
>>>>>>> >>>> const&, char
>>>>>>> >>>> const* const*) + 1221
>>>>>>> >>>> 14 lli 0x000000000040c8b7 main + 6599
>>>>>>> >>>> 15 libc.so.6 0x00007f9c6c7f2be5
>>>>>>> >>>> __libc_start_main + 245
>>>>>>> >>>> 16 lli 0x000000000040a6d1
>>>>>>> >>>> Stack dump:
>>>>>>> >>>> 0. Program arguments:
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli
>>>>>>> >>>> -use-mcjit -relocation-model=pic -code-model=small
>>>>>>> >>>>
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/test/ExecutionEngine/MCJIT/Output/eh-sm-pic.ll.script:
>>>>>>> >>>> line 1: 30636 Aborted
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli -use-mcjit
>>>>>>> >>>> -relocation-model=pic -code-model=small
>>>>>>> >>>>
>>>>>>> >>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll
>>>>>>> >>>>
>>>>>>> >>>> Note that this clang is hardcoded to use libc++
>>>>>>> >>>> (-stdlibc=libc++). Is this
>>>>>>> >>>> good enough?
>>>>>>> >>>>
>>>>>>> >>>> Thanks!
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>> _______________________________________________
>>>>>>> >>> cfe-dev mailing list
>>>>>>> >>> cfe-dev at cs.uiuc.edu
>>>>>>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> cfe-dev mailing list
>>>>>>> >> cfe-dev at cs.uiuc.edu
>>>>>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>
>>>>>
>>>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
More information about the cfe-dev
mailing list