<div dir="ltr"><div><div><div>My long-term plan is to make <clang>/lib/Headers/unwind.h have all essential structs and defines to build libunwind and libc++abi.  It will look similar to the one in <libunwind>/include/unwind.h currently, i.e. guarding different structs and defines with ifdefs.<br></div></div></div><div><div><div><br>Besides, the merged unwind.h should be as standalone as possible.  There should be no external dependencies.  That's the reason why the header from libunwind is still not a drop-in replacement at the moment.  Some code duplication might be necessary.  For example, the code in 
<libunwind>/include/__libunwind_config.h should be duplicated.  However, I don't think this will be a big problem.<br><br>I believe that we should be able to build libunwind and libc++abi with the unwind.h from gcc.  We can add some CMake tests or C++ function overloading to make sure that both <unwind.h> from clang and gcc are supported (I have done some preliminary experiments.)  However, I don't think we can support ALL unwind.h from everywhere (including the header from savannah.)  As you have mentioned that several structs for ARM EHABI are missing from that header.  The idea is that <unwind.h> is a part of the compiler toolchain, thus we should prefer the <unwind.h> comes with the compiler to the one maintained by ourselves.<br><br></div><div>As for the schedule, I plan to update the header in <clang>/lib/Headers/unwind.h after the release of LLVM 3.7.  So that <clang>/lib/Headers/unwind.h and <libunwind>/include/unwind.h will keep in sync in 3.8 release.  After the release of 3.8 branch, I am going to remove the header from libunwind repository.  In case that a libunwind user does not have a latest copy of <unwind.h>, he/she can simply copy the file from <clang>/lib/Headers.<br><br></div><div>Hope this clarifies my plan.  Feel free to let me know if you have any questions.<br></div><div><br></div><div>Sincerely,<br></div><div>Logan<br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 29, 2015 at 1:19 AM, Oleg Ranevskyy <span dir="ltr"><<a href="mailto:llvm.mail.list@gmail.com" target="_blank">llvm.mail.list@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">iid_iunknown added a comment.<br>
<br>
Saleem, Logan,<br>
<br>
Thank you for your remarks.<br>
<br>
Having considered the possibility to unify unwind.h from clang and libunwind, I encountered some differences in the headers making the unification a bit obscure to me. I would greatly appreciate if you could take a look and clarify.<br>
<br>
Libunwind has different declarations for ARM EHABI. E.g., there are different _Unwind_Exception structures, __personality_routine function signatures, libunwind also defines some additional constants for ARM EHABI. If these differences are to be reflected in the unified header, the header will need to see the libunwind's _LIBUNWIND_ARM_EHABI macro. This will result in includes cross-dependency between clang and libunwind. Another way is to define own version of _LIBUNWIND_ARM_EHABI in the clang's unwind.h, but this does not look nice either.<br>
<br>
My another concern is that, if I get it right, libunwind should work properly with any unwind.h. This might be the clang's unwind.h or, for example, the one from savannah. Similarly to the clang's unwind.h, the savannah's unwind.h does not have different / additional declarations for ARM EHABI that the libunwind needs. Hence use of the libunwind with the unwind.h from savannah is not possible. Would you clarify if there are any plans to support such a possibility, please?<br>
<br>
Thank you.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9744&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=ONWoBhkws8u9ivR1DmloeUu9ZyTbTMLYO4klBIP5pfQ&s=CElTSXlAKE99StBjbB7lTKU8SbWQblwMZIvTJEyUOnY&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D9744</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>