[cfe-dev] [RFC] Bump up clang's __GNUC_MINOR__

[Benjamin Kramer]

On 16.05.2012, at 21:09, PaX Team wrote:

> On 16 May 2012 at 18:10, Benjamin Kramer wrote:
> 
>> However the problem is not compiling glibc. That's something
>> completely different that won't ever work with clang unless the glibc
>> maintainers move. It uses extensions that are broken beyond repair
>> like __builtin_apply and -fno-toplevel-reorder, making it a lot worse
>> to deal with than the linux kernel. 
> 
> __builtin_return/__builtin_apply seem to be used in dlfcn/eval.c only
> which is no longer built by glibc since 2004 according to git log.

ah, ok. I guess they left it in the tree for entertainment purposes then.

> -fno-toplevel-reorder can be a real problem, i wonder where glibc relies
> on its behaviour though.

Their runtime stuff (initfini.c) uses a weird mixture of module-level inline
asm and C code which breaks when the compiler doesn't preserve the
order.

> are you aware of any other incompatibility that prevents clang from
> compiling glibc (i'm just preparing mentally for the day i get to try
> this one day ;)?

Apart from integrated-as issues, which is mostly missing support for some
macros and some other minor issues, missing support for tls_model is an
issue, but that should be fixable if someone really cares.

Their configure script also checks for http://llvm.org/bugs/show_bug.cgi?id=12554
which is … crazy.

>> The problem is that glibc uses those extensions in the standard header
>> files (if FORTIFY_SOURCE is specified) so any code base using e.g.
>> stdio.h and FORTIFY_SOURCE will have to change the gcc version clang
>> simulates, which is not acceptable. 
> 
> ok, i misunderstood the original issue as being with glibc itself, not
> with its headers used everywhere else. in that case i suggest that you
> simply ignore this problem and stipulate that distros building with
> clang not define _FORTIFY_SOURCE (it's not a big loss anyway).

It is a hardening feature and there are hundreds of projects out there that
enable it by default in their makefiles. It may not give a lot of value but
discouraging its use will only bring us "clang is insecure" comments and
angry users.

- Ben