<div dir="ltr">FWIW, there's an existing implementation of a unified gcc+clang FORTIFY on top of glibc 2.27: <a href="https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-libs/glibc/files/local/glibc-2.27-clang-fortify.patch" target="_blank">https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-libs/glibc/files/local/glibc-2.27-clang-fortify.patch</a> . 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(*).<div><div><div><div><br></div><div>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 it.</div></div></div><div><br></div><div>(*) - 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.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 12:02 PM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>However, clang does provide other mechanisms by which the same results can be achieved.<div><br>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.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 2:48 PM Martin Storsjö via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 3 Dec 2019, Serge Guelton via cfe-dev wrote:<br>
<br>
> Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic),<br>
><br>
> As a follow-up to that old thread about -D_FORTIFY_SOURCE=n<br>
><br>
>    <a href="http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html</a><br>
><br>
> And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE<br>
> support is claimed to be only partial:<br>
><br>
>    <a href="https://pagure.io/fesco/issue/2020" rel="noreferrer" target="_blank">https://pagure.io/fesco/issue/2020</a><br>
><br>
> I dig into the glibc headers in order to have a better understanding of what's<br>
> going on, and wrote my notes here:<br>
><br>
>    <a href="https://sergesanspaille.fedorapeople.org/fortify_source_requirements.rst" rel="noreferrer" target="_blank">https://sergesanspaille.fedorapeople.org/fortify_source_requirements.rst</a><br>
><br>
> TL;DR: clang does provide a similar compile-time checking as gcc, but no runtime<br>
> checking. To assert that I wrote a small test suite:<br>
><br>
>    <a href="https://github.com/serge-sans-paille/fortify-test-suite" rel="noreferrer" target="_blank">https://github.com/serge-sans-paille/fortify-test-suite</a><br>
><br>
> And indeed, clang doesn't pass it, mostly because it turns call to<br>
> __builtin__(.*)_chk into calls to __builtin__\1.<br>
<br>
I remember looking at the fortify macros recently, and iirc the issue was <br>
that the __builtin_object_size builtin, when used in an inline function, <br>
can't evaluate the size of the object in the context where it is inlined, <br>
which the glibc fortify macros/inline functions depend on.<br>
<br>
This has been discussed before, e.g. here: <br>
<a href="http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html</a><br>
<br>
// Martin<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>