[PATCH RFC] __builtin_dynamic_object_size with -D_FORTIFY_SOURCE=3
Florian Weimer
fweimer@redhat.com
Mon Nov 30 09:11:51 GMT 2020
* 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
More information about the Libc-alpha
mailing list