[PATCH RFC] __builtin_dynamic_object_size with -D_FORTIFY_SOURCE=3

[Florian Weimer]

* Siddhesh Poyarekar:

> -D_FORTIFY_SOURCE=3
> -------------------
>
> I restricted usage of __builtin_dynamic_object_size to a new
> _FORTIFY_SOURCE level because it has one fundamental difference from
> the earlier level, which is that it can pass a variable to the _chk
> function instead of constant.  As a result, 1 and 2 are fast with most
> overhead being optimized out while 3 may have additional overhead.
>
> For example at the moment the simple case of memcpy, memmove,
> etc. where they're implemented with compiler builtins like
> __builtin___memcpy_chk, clang is able to generate compact code that
> passes the expression to __memcpy_chk or just generates a memcpy when
> possible.  In the non-builtin cases though, where the size evaluates
> to an expression, one may see patterns like:
>
> 	cmpq	$-1, %rbx
> 	je	.LBB0_2
> 	callq	fortified_chk
> 	jmp	.LBB0_3
> .LBB0_2:                                # %if.else
> 	callq	fortified
>
> since the compiler isn't smart enough yet to reduce that condition.
> This can be fixed (I'm working on that right now) in the simple case
> of a direct comparison and thus work for _FORTIFY_SOURCE=3, but it may
> be harder to evaluate for __builtin_dynamic_object_size in general
> where the comparison happens indirectly.  This is also why
> __builtin_dynamic_object_size isn't exactly a drop-in replacement for
> __builtin_object_size in all cases.

I think this should be fixed in the compiler, and the level 3 should be
dropped.  A compiler bug is not a good reason to change the external
interface, especially if it is just a performance bug.  The 2 vs 3
choice isn't something that's useful to developers.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill