<div dir="ltr">This should be fixed in r255559 and r255560.<div><br></div><div>@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.</div><div><br></div><div>@Chandlerc The bootstrap should be clean now.</div><div><br></div><div>/Eric</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 8:50 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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)<div><br><div>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:</div><div><br></div><div> -lm -lgcc_s -lpthread -lc -lgcc_s</div><div><br></div><div>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.</div><div>When using and testing libc++abi (via libc++) the link line should look something like:</div><div><br></div><div> -lc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc</div><div><br></div></div><div>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. </div><div><br></div><div>I'll put a patch together tonight.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>/Eric</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 6:26 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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++.<div><br></div><div>I was able to reproduce the bug using the following steps:</div><div><br></div><div>1. export CC=clang CXX=clang++</div><div>2. cmake --DLLVM_ENABLE_LIBCXX=ON -DLLVM_BUILD_PROJECTS=OFF../llvm</div><div>3. ./bin/lli llvm/test/ExecutionEngine/MCJIT/eh.ll</div><div><br></div><div>The above steps assume that you already have libc++.so installed somewhere the linker can find it</div><div>and that libc++.so is a linker script that includes -lc++abi.</div><div><br></div><div>I turned LLVM_BUILD_PROJECTS off so that we aren't contending with two different libc++abi binaries.</div><div><br></div><div>Any help with this bug would be appreciated.</div><span><font color="#888888"><div><br></div><div>/Eric</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:27 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yep.</div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 9, 2015 at 8:21 PM Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Chandler, I'm assuming your still able to reproduce the issue?</div></div><div dir="ltr"><div><br></div><div>/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 3:06 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">(Moving to the new mailing list)<br><br><div class="gmail_quote"><span><div dir="ltr">On Wed, Nov 26, 2014 at 10:09 PM Evgeniy Stepanov <<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>> wrote:<br></div></span><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">#0 0x00007ffff62b5bb9 in __GI_raise (sig=sig@entry=6) at<br>
../nptl/sysdeps/unix/sysv/linux/raise.c:56<br>
#1 0x00007ffff62b8fc8 in __GI_abort () at abort.c:89<br>
#2 0x00007ffff7b60807 in abort_message (format=0x7ffff7bcdf13<br>
"terminating with %s exception of type %s") at<br>
../projects/libcxxabi/src/abort_message.cpp:66<br>
#3 0x00007ffff7b60ad6 in default_terminate_handler () at<br>
../projects/libcxxabi/src/cxa_default_handlers.cpp:68<br>
#4 0x00007ffff7bc454e in std::__terminate (func=0x7ffff7b60900<br>
<default_terminate_handler()>) at<br>
../projects/libcxxabi/src/cxa_handlers.cpp:68<br>
#5 0x00007ffff7bc31dd in __cxxabiv1::failed_throw<br>
(exception_header=0x1e87240) at<br>
../projects/libcxxabi/src/cxa_exception.cpp:149<br>
#6 0x00007ffff7bc3136 in __cxa_throw (thrown_object=0x1e872b8,<br>
tinfo=0x7ffff7dd83b0 <typeinfo for int>, dest=0x0) at<br>
../projects/libcxxabi/src/cxa_exception.cpp:244<br>
#7 0x00007ffff7ff502d in throwException ()<br>
#8 0x00007ffff7ff503d in main ()<br>
#9 0x0000000000beef04 in llvm::MCJIT::runFunction (this=0x1e74c30,<br>
F=0x1e6b4b0, ArgValues=...) at<br>
../lib/ExecutionEngine/MCJIT/MCJIT.cpp:500<br>
#10 0x0000000000b26f90 in llvm::ExecutionEngine::runFunctionAsMain<br>
(this=0x1e74c30, Fn=0x1e6b4b0, argv=..., envp=0x7fffffffe0d0)<br>
at ../lib/ExecutionEngine/ExecutionEngine.cpp:393<br>
#11 0x0000000000567cc4 in main (argc=4, argv=0x7fffffffe0a8,<br>
envp=0x7fffffffe0d0) at ../tools/lli/lli.cpp:613<br></blockquote><div><br></div></div></div><div>Any update here Eric? Or others? Would really like to get the bootstrap clean with libc++abi.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Wed, Nov 26, 2014 at 11:37 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br>
> Evgeniy,<br>
><br>
> Would you be willing to reproduce this again but in debug mode instead<br>
> of release so we get a better stack trace?<br>
><br>
> /Eric<br>
><br>
> On Wed, Nov 26, 2014 at 5:20 AM, Evgeniy Stepanov<br>
> <<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>> wrote:<br>
>> I've got the same issue.<br>
>> On Linux (Trusty/x86_64), build clang with libc++/libc++abi (just<br>
>> plain ninja clang cxx cxxabi w/o any special cmake flags), then use it<br>
>> to bootstrap clang like this:<br>
>><br>
>> CC=/code/llvm/build2/bin/clang \<br>
>> CXX=/code/llvm/build2/bin/clang++ \<br>
>> LDFLAGS="-lc++abi -L/code/llvm/build2/lib -Wl,-rpath,/code/llvm/build2/lib" \<br>
>> cmake \<br>
>> -GNinja \<br>
>> -DCMAKE_BUILD_TYPE=Release \<br>
>> -DLLVM_ENABLE_LIBCXX=ON \<br>
>> ..<br>
>><br>
>> In the second tree, MCJIT tests fail with the same error:<br>
>><br>
>> ./bin/lli -relocation-model=pic -code-model=large<br>
>> ../test/ExecutionEngine/MCJIT/eh-lg-pic.ll<br>
>> terminating with uncaught exception of type int<br>
>> 0 lli 0x0000000000a80a9a<br>
>> _ZN4llvm3sys15PrintStackTraceEP8_IO_FILE + 42<br>
>> 1 lli 0x0000000000a81eeb<br>
>> 2 libpthread.so.0 0x00007f83baabf340<br>
>> 3 libc.so.6 0x00007f83b9d2fbb9 gsignal + 57<br>
>> 4 libc.so.6 0x00007f83b9d32fc8 abort + 328<br>
>> 5 libc++abi.so.1 0x00007f83bb5121a7<br>
>> 6 libc++abi.so.1 0x00007f83bb512355<br>
>> 7 libc++abi.so.1 0x00007f83bb55c3b3<br>
>> 8 libc++abi.so.1 0x00007f83bb55bb66 __cxa_throw + 166<br>
>> 9 libc++abi.so.1 0x00007f83bb98802d __cxa_throw + 4375917<br>
>> 10 libc++abi.so.1 0x00007f83bb98803d __cxa_throw + 4375933<br>
>> 11 lli 0x0000000000849649<br>
>> _ZN4llvm5MCJIT11runFunctionEPNS_8FunctionERKNSt3__16vectorINS_12GenericValueENS3_9allocatorIS5_EEEE<br>
>> + 1209<br>
>> 12 lli 0x00000000007ecd08<br>
>> _ZN4llvm15ExecutionEngine17runFunctionAsMainEPNS_8FunctionERKNSt3__16vectorINS3_12basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEENS8_ISA_EEEEPKPKc<br>
>> + 1192<br>
>> 13 lli 0x000000000050c434 main + 10404<br>
>> 14 libc.so.6 0x00007f83b9d1aec5 __libc_start_main + 245<br>
>> 15 lli 0x00000000005092fb<br>
>> Stack dump:<br>
>> 0. Program arguments: ./bin/lli -relocation-model=pic<br>
>> -code-model=large ../test/ExecutionEngine/MCJIT/eh-lg-pic.ll<br>
>> Aborted (core dumped)<br>
>><br>
>> On Sat, Aug 16, 2014 at 9:24 AM, İsmail Dönmez <<a href="mailto:ismail@donmez.ws" target="_blank">ismail@donmez.ws</a>> wrote:<br>
>>> Ping?<br>
>>><br>
>>> On Jul 17, 2014 11:05 AM, "İsmail Dönmez" <<a href="mailto:ismail@donmez.ws" target="_blank">ismail@donmez.ws</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>><br>
>>>> On Wed, Jul 16, 2014 at 6:43 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:<br>
>>>>><br>
>>>>> On Wed, Jul 16, 2014 at 4:10 AM, İsmail Dönmez <<a href="mailto:ismail@donmez.ws" target="_blank">ismail@donmez.ws</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi,<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Mon, Jul 14, 2014 at 8:10 PM, Dan Albert <<a href="mailto:danalbert@google.com" target="_blank">danalbert@google.com</a>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Submitted (with some slight modifications, s/libgcc_s/libgcc_eh/) as<br>
>>>>>>> r212958. Tested with and without the LLVM unwinder, and things look good.<br>
>>>>>>> Thanks again!<br>
>>>>>><br>
>>>>>><br>
>>>>>> Changing gcc_s with gcc_eh doesn't look good. libcxxabi tests pass but<br>
>>>>>> llvm MCJIT exception tests fail with:<br>
>>>>>><br>
>>>>>> "terminating with uncaught exception of type int"<br>
>>>>><br>
>>>>><br>
>>>>> Can you try to make a reduced test case for libcxxabi from this?<br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Smallest test cases are<br>
>>>> test/ExecutionEngine/MCJIT/{eh-sm-pic,eh-lg-pic}.ll<br>
>>>><br>
>>>> Both fail the same way:<br>
>>>><br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli -use-mcjit<br>
>>>> -relocation-model=pic -code-model=small<br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll<br>
>>>> --<br>
>>>> Exit Code: 134<br>
>>>><br>
>>>> Command Output (stderr):<br>
>>>> --<br>
>>>> terminating with uncaught exception of type int<br>
>>>> 0 libLLVMSupport.so 0x00007f9c6ddf7d85<br>
>>>> llvm::sys::PrintStackTrace(_IO_FILE*) + 37<br>
>>>> 1 libLLVMSupport.so 0x00007f9c6ddf83f3<br>
>>>> 2 libpthread.so.0 0x00007f9c6d0d79f0<br>
>>>> 3 libc.so.6 0x00007f9c6c806849 gsignal + 57<br>
>>>> 4 libc.so.6 0x00007f9c6c807cd8 abort + 328<br>
>>>> 5 libc++abi.so.1 0x00007f9c6cb89237<br>
>>>> 6 libc++abi.so.1 0x00007f9c6cb894b6<br>
>>>> 7 libc++abi.so.1 0x00007f9c6cbeda7e<br>
>>>> 8 libc++abi.so.1 0x00007f9c6cbec6ed<br>
>>>> 9 libc++abi.so.1 0x00007f9c6cbec646<br>
>>>> 10 libc++abi.so.1 0x00007f9c6ff3001c<br>
>>>> 11 libc++abi.so.1 0x00007f9c6ff30026<br>
>>>> 12 libLLVMMCJIT.so 0x00007f9c6e61fd27<br>
>>>> llvm::MCJIT::runFunction(llvm::Function*,<br>
>>>> std::__1::vector<llvm::GenericValue, std::__1::allocator<llvm::GenericValue><br>
>>>> > const&) + 919<br>
>>>> 13 libLLVMExecutionEngine.so 0x00007f9c6f34fa65<br>
>>>> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,<br>
>>>> std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>,<br>
>>>> std::__1::allocator<char> >,<br>
>>>> std::__1::allocator<std::__1::basic_string<char,<br>
>>>> std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, char<br>
>>>> const* const*) + 1221<br>
>>>> 14 lli 0x000000000040c8b7 main + 6599<br>
>>>> 15 libc.so.6 0x00007f9c6c7f2be5 __libc_start_main + 245<br>
>>>> 16 lli 0x000000000040a6d1<br>
>>>> Stack dump:<br>
>>>> 0. Program arguments: /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli<br>
>>>> -use-mcjit -relocation-model=pic -code-model=small<br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll<br>
>>>><br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/test/ExecutionEngine/MCJIT/Output/eh-sm-pic.ll.script:<br>
>>>> line 1: 30636 Aborted<br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/stage2/./bin/lli -use-mcjit<br>
>>>> -relocation-model=pic -code-model=small<br>
>>>> /home/abuild/rpmbuild/BUILD/llvm/test/ExecutionEngine/MCJIT/eh-sm-pic.ll<br>
>>>><br>
>>>> Note that this clang is hardcoded to use libc++ (-stdlibc=libc++). Is this<br>
>>>> good enough?<br>
>>>><br>
>>>> Thanks!<br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>