Re: [PATCH 1/2] string: _FORTIFY_SOURCE=3 using __builtin_dynamic_object_size

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 12/28/20 10:14 PM, Adhemerval Zanella via Libc-alpha wrote:
> For previous discussion I couldn't really grap what is the GCC intention
> regarding this new builtin. Would it willing to implement with the same
> semantic as LLVM has done or depending of result when glibc starts to
> provide it GCC will either change its semantic or not implement at all?

The original conversation around it is here[1], although the 
conversation is more about extending __builtin_object_size vs 
introducing a new builtin (i.e. the __builtin_dynamic_object_size that 
eventually went into llvm).

My understanding from that conversation is that the gcc community sees 
value in the builtin and is willing to consider it as long as its 
semantics are comprehensively documented.  Right now the only real 
explanation for __builtin_dynamic_object_size is that "it's like 
__builtin_object_size", which is inaccurate and misleading.

I wanted to do this first too, i.e. document 
__builtin_dynamic_object_size semantics and work on getting it included 
in gcc but I couldn't make the gcc stage 1 deadline (which was last 
month) and decided to pick it up in 2021.

> If the former, using _FORTIFY_SOURCE=3 should be fine.  However, if it
> is the latter I think it would be better to add it as another and different
> FORTIFY flag ( _FORTIFY_SOURCE_DYNAMIC or something like that).
> 
> I really want to avoid the issue where developers would not see the
> expected code generation when using _FORTIFY_SOURCE=3 with gcc or the worse,
> where _FORTIFY_SOURCE=3 would have different semantic depending of the
> compiler used.

I don't foresee semantic differences diverging enough to be a 
compatibility issue for developers using _FORTIFY_SOURCE=3.  At worst, 
it could result in developers either seeing performance differences 
(because one compiler emits better code than the other due to the kind 
of information it chooses to glean and retain from the builtin) or is 
able to (or not) fortify functions, again because of how well it can 
deduce object sizes.  Such differences already exist in 
__builtin_object_size.

Does that address your concern?

> This should be in a different patch, where glibc would handle not support
> _FORTIFY_SOURCE levels and emit the expected warnings.

OK.

> I think from previous version that Florian suggested renamed this internal macros
> to __glibc_objsize[0].

Hmm, I missed that.  I'll rename it to __glibc_objsize.

Thanks,
Siddhesh

[1] https://gcc.gnu.org/legacy-ml/gcc/2019-01/msg00188.html