Sorry, I don't have time to work on this recently. Here's the plan:

Yeah. It is a kind of similar. Another route is to move the code from <libunwind>/include/unwind.h to <clang>/lib/Headers and then ship a shim layer with libc++abi and/or libunwind for old clang.

Thanks for reviewing. Committed as rL286760.

Thanks. Committed as rL286759.

Would you mind if I commit this patch as-is? I believe OFF will is the better default value for ARM as well. Thanks.

For atomic-cmpxchg.ll, I found that your output is the same as the version I originally committed. The test was updated by @danielcdh in D24818 / rL284757. You may wish to add him as reviewer.

Thanks for your comment.

Hi @EricWF and @mclow.lists:

Refine assertions to address the comments from mclow.lists.

Ping? Any other comments?

Thanks for reviewing. Committed as rL283118 with the suggested change regarding to is_sh_test assertion.

Ping. Any further comments? Or, should we duplicate <unwind.h> in multiple repositories?

Thanks for reviewing. Committed as rL283100.

Hi @rengolin and @EricWF,

Thanks. Committed as rL280484.

In D24084#532724, @asl wrote:

I totally agree with Renato. What part of libc++abi requires exactly libunwind's unwind.h, what is the dependency?

In D24084#530433, @rengolin wrote:

That is a horrible dependency... I never hit it because I always test libc++ with libunwind.

Sorry for the late reply. Thanks for your work. Yes, this is correct.

Yes. This is what we have today.

The simple replacement from throw() to _NOEXCEPT looks fine.

Committed as rL263010.

Note: I have tested this change on Debian Jessie (armhf). It works without problems.

Look good to me.

I have committed this change as rL262178. Thanks for your work.

LGTM. It is good to go now.

In general, it looks good to me if the comments are addressed.

I have tested your patch. It can't be compiled with clang because several types and defines are missing from <clang>/lib/Headers/unwind.h. Thus, submitting this patch will break all self-bootstrapping build.

Sorry for the late reply. I spent sometime to setup the testing environment.

In D15781#317533, @compnerd wrote:

I didn't mean to imply the C++ personality. The reconfiguration of the C personality makes things harder IMO. Now you need to rebuild the library if something changes and control that. If you absolutely must use this approach, why not introduce a new routine that dispatches as you want (just to be clear this would be different from the language specific personality)? The entire thing with the personalities is that they handle things one way only and you switch the one that is used.

In D15781#317439, @compnerd wrote:

Also, neighter LLVM nor GCC would produce references to this personality routine, so it seems odd to support this.

Thanks! Committed as rL256241.

@echristo: IMO, I prefer not to add such comment for two reasons:

In D13104#252365, @logan wrote:

I was only testing clang+ld.bfd and clang+ld.gold at the time.

In D13104#251958, @dsanders wrote:

It was Android that asked us to get read-only .eh_frame working properly for Mips so I might have two opposing requests from the same project.

LGTM. Tested on x86_64 and arm-linux-gnueabihf.

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.

Thanks for reviewing. Committed as rL243073.

Since there's no way to remove libraries from the list (because the compiler adds them), there is no way a warning would be effective. Ie. the user would get a warning and would be able to do nothing.

Please have a look on the revised version. This should address all of the comments at the moment. I really wish to commit this change before 3.7 release. Thanks.

Stash the changes from D11191.

Stashing the change with D11190.

Thanks for reviewing!

May you further elaborate your idea? I don't quite understand why should we install the headers of libunwind for libcxx?

For your use case, please have a look at the upcoming D11191. I believe it should work for you. Although I am really hesitating, I have just confirmed that Savannah libunwind[1] is working on ARM. So I am not strongly oppose to the idea now.

Address asl's comment.

I have some concern on the design of this change. IMO, it is unintuitive that one -l option will affect the other -l options. Can't we simply rely on --rtlib=compiler-rt? Or, alternatively, can we simply emit a warning instead of changing the behavior quietly? Thanks.

Hi Renato,

Hi Renato,

Add test cases for 64/128-bit vector types.