[llvm-dev] [cfe-dev] clang and -D_FORTIFY_SOURCE=1

[Joerg Sonnenberger via llvm-dev]

On Tue, Dec 03, 2019 at 09:48:00PM +0200, Martin Storsjö via cfe-dev 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 -D_FORTIFY_SOURCE
> > 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 what's
> > going on, and wrote my notes here:
> > 
> >    https://sergesanspaille.fedorapeople.org/fortify_source_requirements.rst
> > 
> > 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:
> http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html

That discussion is no longer relevant. __bos is only lowered to a
result, if the answer is definitely known and otherwise kept through a
good chunk of the pass pipeline, most importantly until after inlining
is done.

Joerg