[cfe-dev] Clang++ and _FORTIFY_SOURCE: Supported or not?

[John Snow via cfe-dev]

On 11/02/2015 07:57 PM, Richard Smith wrote:
> On Mon, Nov 2, 2015 at 4:27 PM, John Snow via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 
>     Hi, all:
> 
>     I'm trying to find an official notice of support (or a contrary notice)
>     for Clang++ and -D_FORTIFY_SOURCE=2.
> 
>     The QEMU project ran into an issue recently [1] where Clang++
>     (3.5.0-9.fc22) failed to compile certain files because it does not have
>     definitions for __builtin_va_pack_len (and friends). This kicks up
>     errors when using glibc, cstdio and _FORTIFY_SOURCE together.
> 
> 
> We still do not support __builtin_va_pack_len and friends (and other
> semantic requirements of fortify that rely on details of GCC's phase
> ordering). We provide other extensions that can be used to implement
> (most of) the functionality of -D_FORTIFY_SOURCE, but the maintenance
> cost to us of supporting those GCC builtins directly is sufficiently
> high that we don't (currently) intend to do so.
> 

That's fine. I want to avoid using something that doesn't have
first-class support, so "no" is every bit as useful as "yes" here.

>     When researching the problem, we ran across an llvm bug [2] where
>     Richard Smith states: "_FORTIFY_SOURCE + glibc + clang is not supported
>     and does not wois, so thanks!rk".
> 
>     However, in testing Clang++ 3.7.0-1.fc23, I notice that
>     -D_FORTIFY_SOURCE does indeed appear to work. Is that a fluke, or do
>     modern versions (>3.5.0) of Clang actually support this combination?
> 
> 
> Current glibc headers use __builtin_va_arg_* only for GCC 4.3 onwards,
> and Clang claims to be GCC 4.2. It's still an unsupported combination,
> and while it might compile, some of the checks are unlikely to work
> because they require a frontend inliner to be useful (for instance, some
> of them require __builtin_object_size to look through function call
> boundaries before the frontend type information is erased). We have
> heard reports from users that the combination of Clang and glibc fortify
> is not currently useful for them.
> 

I wonder what's going on for 3.5.0-9.fc22, then -- it's picking up those
definitions somehow. (Oh well, maybe not a mystery worth solving...?)

> If it works for you and provides value, that's great, but you should be
> aware that the support story is likely to be worse than usual for an
> open-source project: all of the effort I can see on the Clang side for
> fortify-like features is being directed towards creating a more
> principled set of language extensions (and using them to implement
> fortify-like features in various flavours of libc) rather than directly
> supporting the existing GCC set. Some of these are a close or exact
> match to the GCC extension (such as our support for
> __builtin_object_size and __builtin_constant_p), and some are not (such
> as our enable_if attribute and upcoming pass_object_size attribute).
> 

I understand. I will discontinue usage of _FORTIFY_SOURCE entirely (when
using clang) instead of hoping that maybe it sometimes works and having
a pretty bad day when it doesn't.

Primarily, since I was having problems with an older version and it
"magically resolved" for newer versions, I wanted to make sure that the
info I had gleaned from the bug tracker was still the accurate picture.

Which... it appears to be, so thanks!

--js

>     I can't find official documentation pointing towards either support or
>     exclusion of this feature, so a firm answer pointing to either direction
>     would be helpful.
> 
>     Thank you,
>     --John Snow
> 
>     [1] QEMU discussion:
>     https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06997.html
>     [2] https://llvm.org/bugs/show_bug.cgi?id=23277#c2
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>