[cfe-dev] [libcxxabi] Contributing ARM EHABI support for libcxxabi

[Howard Hinnant]

I've no objection to a CMake system being put in.  There's also one already in libcxx.  Don't ask me to maintain it, I'm not qualified.  And please don't delete the existing low-tech buildit script.

Howard

On Dec 4, 2013, at 6:18 PM, Nico Weber <thakis at chromium.org> wrote:

> Given that cmake is used widely in the rest of llvm, it makes sense to me to use it here too – but Howard has expressed resistance in the past, so I guess it's up to him :-) Maybe that decision can be made independent of the rest and we can go with the tweak to what is there today?
> 
> 
> On Wed, Dec 4, 2013 at 3:08 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Wed, Dec 4, 2013 at 2:44 PM, Nick Kledzik <kledzik at apple.com> wrote:
> On Dec 4, 2013, at 12:56 PM, Nico Weber <thakis at chromium.org> wrote:
> 
>> 
>> > 3.) r192136 didn’t add any test – how should testing of unwinding code work? Is running the exception tests in the libc++ suite enough?
>> The Darwin libunwind project (http://opensource.apple.com/source/libunwind/libunwind-35.3/) on which this was based had some a small test suite, but it did not fit into the existing libcxxabi test suite which assumes target==host and every test is one .cpp file.
>> 
>> Ok. I tried running at least the libc++abi test suite to make sure we don't completely break exception handling on darwin, but it looks like the buildit script doesn't build libunwind, and if I try to get it to compile (attached), the compiler complains about mach-o/dyld_priv.h – is it currently possible to run libc++abi tests for the Unwind bits of libc++abi on darwin?
>> 
>> If I copy http://www.opensource.apple.com/source/dyld/dyld-132.13/include/mach-o/dyld_priv.h?txt to include/mach-o/dyld_priv.h and build with the attached script, I'm able to build a libunwind.dylib that passes the tests and that fails them if I add an early return to _Unwind_RaiseException. Would adding dyld_priv.h and landing the attached patch be a good first step?
> 
> Regarding dyld_priv.h, since it is always on my system in /usr/local/include, I had not realized the unwinder had that dependency.  I posted a patch earlier to get the unwinder building on older darwins which did not have dyld support.  I can update that patch so that the unwinder never need dyld_priv.h.
> 
> Regarding the build system, I think it brings up the bigger issue of what sort of build system we want for libcxxabi.  The script is a quick way to get building.  But, it is not how Apple actual builds the shipping libunwind (which is a local xcode project).  What sort of build system would others like?
> 
> Unless there is an overwhelming need to invest in something more custom, I would vote for cmake. I'm still holding out hope for an end to build system proliferation.
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev