r224934 - Effectively revert r151058 which caused Clang's unwind.h to defer to

[Richard Smith]

On Mon, Dec 29, 2014 at 5:29 AM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> Author: chandlerc
> Date: Mon Dec 29 07:29:38 2014
> New Revision: 224934
>
> URL: http://llvm.org/viewvc/llvm-project?rev=224934&view=rev
> Log:
> Effectively revert r151058 which caused Clang's unwind.h to defer to
> libunwind in all cases when installed.
>
> At the time, Clang's unwind.h didn't provide huge chunks of the
> LSB-specified unwind interface, and was generally too aenemic to use for
> real software. However, it has since then become a strict superset of
> the APIs provided by libunwind on Linux. Notably, you cannot compile
> llgo's libgo library against libunwind, but you can against Clang's
> unwind.h. So let's just use our header. =] I've checked pretty
> thoroughly for any incompatibilities, and I am not aware of any.
>

This causes problems for modules-enabled builds. Specifically, Clang goes
to efforts to ensure that its own unwind.h is included in any module that
contains a system unwind.h, which now results in errors due to conflicting
redefinitions of the contents of the header. For instance:

While building module '_Builtin_intrinsics' imported from
test/Modules/compiler_builtins.m:7:
While building module '__usr_include' imported from
lib/clang/3.6.0/include/mm_malloc.h:27:
In file included from <module-includes>:57:
/usr/include/unwind.h:42:5: error: redefinition of enumerator '_URC_NO_REASON'
    _URC_NO_REASON = 0,
    ^
lib/clang/3.6.0/include/unwind.h:81:3: note: previous definition is here
  _URC_NO_REASON = 0,
  ^

For all the other builtin headers we provide, it's harmless to include both
our header and the system one, but that's no longer true for this one. I
have no real preference for how this should be fixed; if we don't want to
make it possible to include both this header and the system one, the
easiest fix might be to teach the modules code that our header replaces the
system one, rather than augmenting it, when named in a module map for a
system header.

An open question is whether or not we should continue to munge
> GNU_SOURCE here. I didn't touch that as it potentially has compatibility
> implications on systems I cannot easily test -- Darwin. If a Darwin
> maintainer can verify that this is in fact unnecessary and remove it,
> cool. Until then, leaving it in makes this change a no-op there, and
> only really relevant on Linux systems where it is pretty clearly the
> right way to go.
>
> Modified:
>     cfe/trunk/lib/Headers/unwind.h
>
> Modified: cfe/trunk/lib/Headers/unwind.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/unwind.h?rev=224934&r1=224933&r2=224934&view=diff
>
> ==============================================================================
> --- cfe/trunk/lib/Headers/unwind.h (original)
> +++ cfe/trunk/lib/Headers/unwind.h Mon Dec 29 07:29:38 2014
> @@ -26,8 +26,8 @@
>  #ifndef __CLANG_UNWIND_H
>  #define __CLANG_UNWIND_H
>
> -#if __has_include_next(<unwind.h>)
> -/* Darwin (from 11.x on) and libunwind provide an unwind.h. If that's
> available,
> +#if defined(__APPLE__) && __has_include_next(<unwind.h>)
> +/* Darwin (from 11.x on) provide an unwind.h. If that's available,
>   * use it. libunwind wraps some of its definitions in #ifdef _GNU_SOURCE,
>   * so define that around the include.*/
>  # ifndef _GNU_SOURCE
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150102/b1bdf040/attachment.html>