[PATCH 1/3] Don't add access size hints to fortifiable functions

[Adhemerval Zanella]

On 19/10/2021 15:19, Siddhesh Poyarekar wrote:
> On 10/19/21 23:24, Adhemerval Zanella wrote:
>>
>>
>> On 12/10/2021 13:16, Siddhesh Poyarekar via Libc-alpha wrote:
>>> In the context of a function definition, the size hints imply that the
>>> size of an object pointed to by one parameter is another parameter.
>>> This doesn't make sense for the fortified versions of the functions
>>> since that's the bit it's trying to validate.
>>>
>>> This is harmless with __builtin_object_size since it has fairly simple
>>> semantics when it comes to objects passed as function parameters.
>>> With __builtin_dynamic_object_size we could (as my patchset for gcc[1]
>>> already does) use the access attribute to determine the object size in
>>> the general case but it misleads the fortified functions.
>>>
>>> Disable the access attribute for fortified function inline functions
>>> when building at _FORTIFY_SOURCE=3 to make this work better.  The
>>
>> By 'work better' do you mean better code generation or better diagnostics
>> from gcc?
> 
> Basically the problem occurs when access attributes are present on regular functions that have inline fortified definitions to generate _chk variants; the attributes get inherited by these definitions, causing problems when analyzing them.  For example with poll(fds, nfds, timeout), nfds is hinted using the __attr_access as being the size of fds.
> 
> Now, when analyzing the inline function definition in bits/poll2.h, the compiler sees that nfds is the size of fds and tries to use that information in the function body.  In _FORTIFY_SOURCE=3 case, where the object size could be a non-constant expression, this information results in the conclusion that nfds is the size of fds, which defeats the purpose of the implementation because we're trying to check here if nfds does indeed represent the size of fds.  Hence for this case, it is best to not have the access attribute.
> 
> With the attributes gone, the expression evaluation should get delayed until the function is actually inlined into its destinations.

Thanks for the explanation, could you add this on the commit message
to make clear the change is to improve compiler diagnosis? 

> 
>>> access attributes remain for the _chk variants since they can be used
>>> by the compiler to warn when the caller is passing invalid arguments.
>>>
>>> Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
>>
>> The change looks ok, but what about other function that use
>> __attr_access ((__write_only__, ...). Should they be adapated as well?
> 
> Only functions that have a fortified implementation need to be changed, which is basically all of the functions below.
> 
>> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
>>
> 
> Thanks,
> Siddhesh