[cfe-dev] libcxx, libcxxabi, and runtime_error - solved

[Marshall Clow]

On May 30, 2014, at 4:56 AM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:

> I found the root cause.  The pertinent clue was in the stackoverflow article: "gcc will, on sufficient optimization levels, actually alias the symbols to the same code".  It turns out that clang/llvm does this aliasing.  For our architecture, there is (soon to be 'was') a bug in some code in AsmPrinter::doFinalization specifically added to support our assembler semantics which was causing the final alias to not appear in our .s file (we do not yet directly generate object files)

Glad to hear that you found the problem.

— Marshall


> 
> Regards,
> 
> 	Richard Gorton
> 
> On May 28, 2014, at 2:20 PM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:
> 
>> Do I need to configure llvm/clang 3.3 with --enable-cxx11 to build libcxx/libcxxabi?
>> 
>> 
>> On May 27, 2014, at 3:44 PM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:
>> 
>>> Thank you for the quick response.  As an experiment, I did an svn export of both libcxx/libcxxabi from the current llvm project, and applied my porting changes to my local copy.
>>> Unfortunately I still hit the same problem.  I did observe that I did have a: "#define LIBCXXRT 1" in my libcxx/include/__config for my architecture, which I think is incorrect (but I'm not clear about what impact it has).
>>> 
>>> I'll keep investigating, and report back with whatever I find.
>>> 
>>> Have others been able to do a libcxx/libcxxabi port to an architecture which does not already have a backing gcc+libs?
>>> 
>>> Regards,
>>> 
>>> 	Richard Gorton
>>> 
>>> 
>>> On May 27, 2014, at 10:42 AM, Marshall Clow <mclow.lists at gmail.com> wrote:
>>> 
>>>> 
>>>> On May 27, 2014, at 6:09 AM, Richard Gorton <rcgorton at cognitive-electronics.com> wrote:
>>>> 
>>>>>> Hi - I'm trying to get C++ support for our architecture up and working (as a cross compiled environment) and I'm encountering some link errors:
>>>>>> 
>>>>>> build/lib/libc++.a(locale.cpp.o):(.data.rel.ro+0x2d0): undefined reference to `std::runtime_error::~runtime_error()'
>>>>>> 
>>>>>> 
>>>>>> When I nm libcxx:locale.cpp.o, I see:
>>>>>>            U _ZNSt13runtime_errorD1Ev
>>>>>> 
>>>>>> 
>>>>>> In libcxxabi:stdexcept.o, I see:
>>>>>> 0000000000000150 T _ZNSt13runtime_errorD0Ev
>>>>>>            U _ZNSt13runtime_errorD1Ev
>>>>>> 00000000000001f8 T _ZNSt13runtime_errorD2Ev
>>>>>> 
>>>>>> That is, in both cases, …runtime_errorD1Ev is undefined.
>>>>>> 
>>>>>> When I use c++filt to demangle the symbols listed in stdexcept.o, they all decode to
>>>>>> 	std::runtime_error::~runtime_error()
>>>>>> 
>>>>>> 
>>>>>> Any suggestions as to how to determine what is happening and why?
>>>>>> 
>>>>>> My setup: clang/llvm 3.3, with libcxx from the 3.3 release; libcxxabi is much more recent (6-May-2014, svn rev 208087)
>>>> 
>>>> I’m guessing that that’s your problem.
>>>> ISTR that there was some migration of destructors between libc++ and libc++abi in the 3.3/3.4 time frame.
>>>> (Though I would have expected multiple definitions, rather than no one defining it).
>>>> 
>>>> If you’re using libc++abi, then it should define the destructors for standard library exception classes.
>>>> 
>>>> — Marshall
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
>