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

[Martin Storsjö via llvm-dev]

On Tue, 3 Dec 2019, Joerg Sonnenberger via cfe-dev wrote:

> 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.

Oh, ok.

Hmm, when I looked at some cases of it (_FORTIFY_SOURCE macros in 
mingw-w64, modelled after the ones in glibc), __bos didn't seem to be able 
to figure out the size as long when the use of it was in an inlined 
function (built with optimization) while the buffer to measure was in the 
caller's scope. As I found that ML post I didn't dig into the matter 
further. Maybe I should look at it again why it didn't work, if it is 
supposed to work these days...

// Martin