[llvm-dev] [cfe-dev] clang and -D_FORTIFY_SOURCE=1
George Burgess IV via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 3 14:44:13 PST 2019
FWIW, there's an existing implementation of a unified gcc+clang FORTIFY on
top of glibc 2.27:
. For the reasons James mentioned, this needs a hefty amount of macro
magic, and there're always going to be discrepancies in what GCC catches vs
what Clang catches(*).
Upstream glibc was generally receptive to the changes when I proposed them
a while back, but I haven't found the time to push it through. I'm more
than happy to help as I can if someone wants to pick that up and run with
(*) - especially in the realm of compiler diags, and as we need to inline N
callers and are expecting -D_FORTIFY_SOURCE=2-level accuracy. Happy to
elaborate if it'd be helpful.
On Tue, Dec 3, 2019 at 12:02 PM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The glibc implementation of FORTIFY_SOURCE is indeed not compatible with
> clang, because it uses compiler extensions which were trivial to implement
> in GCC's architecture, but difficult/impossible in clang's.
> However, clang does provide other mechanisms by which the same results can
> be achieved.
> If anyone is interested in glibc fully supporting fortify mode with clang,
> way to achieve this would be to look at the implementation in the bionic
> libc's headers, and then implement the same technique in glibc.
> On Tue, Dec 3, 2019 at 2:48 PM Martin Storsjö via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> On Tue, 3 Dec 2019, Serge Guelton via cfe-dev wrote:
>> > Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic),
>> > As a follow-up to that old thread about -D_FORTIFY_SOURCE=n
>> > http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html
>> > And, more recently, to this fedora thread where clang/llvm
>> > support is claimed to be only partial:
>> > https://pagure.io/fesco/issue/2020
>> > I dig into the glibc headers in order to have a better understanding of
>> > going on, and wrote my notes here:
>> > TL;DR: clang does provide a similar compile-time checking as gcc, but
>> no runtime
>> > checking. To assert that I wrote a small test suite:
>> > https://github.com/serge-sans-paille/fortify-test-suite
>> > And indeed, clang doesn't pass it, mostly because it turns call to
>> > __builtin__(.*)_chk into calls to __builtin__\1.
>> I remember looking at the fortify macros recently, and iirc the issue was
>> that the __builtin_object_size builtin, when used in an inline function,
>> can't evaluate the size of the object in the context where it is inlined,
>> which the glibc fortify macros/inline functions depend on.
>> This has been discussed before, e.g. here:
>> // Martin
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev