On 5/17/22 00:30, Aaron Puchert wrote:
Am 16.05.22 um 08:44 schrieb Martin Liška:
On 5/14/22 00:48, Aaron Puchert wrote:
Am 13.05.22 um 15:19 schrieb Dominique Leuenberger / DimStar:
* Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2 Is that really a good default though? The RedHat blog [1] writes
Earlier _FORTIFY_SOURCE levels rely on constant object sizes; because of this, the runtime overhead is negligible. _FORTIFY_SOURCE=3, however, changes that because expressions used to compute the object size can be arbitrarily complex. Complex expressions can add arbitrarily more runtime overhead. Further, consider the possibility of do_something in the previous example being called in a loop; the overhead gets magnified. Hi.
We hope the overhead will be reasonable even though it's not so constant as FS=2. If there are affected packages, we can drop the fortification level for them.
It might be hard to notice whether a package is affected because we don't regularly benchmark most packages. It probably doesn't show up in profiles, because the checks are added inline. So unless it's very obvious (say an increase of 30% or so), I think it would just fall under the radar. I'd expect us to notice only a small portion of the regressions caused by this (whatever the total might be).
That's correct, however based on my preliminary measurements that overall code grows seems negligible and so I don't expect much more instructions from __builtin_dynamic_object_size. Note that result of the built-in call is very commonly shared with calls to malloc, realloc and similar functions. What can be problematic are memory-related functions (__memcpy_chk, __memmove_chk, __mempcpy_chk and __memset_chk), these can theoretically lead to a slowdown if being used in a loop. The other functions are string-related functions (__stpcpy_chk, ..) and these are overhead itself. I must agree that we as openSUSE really lack a package performance system. Martin
Another issue is that e.g. more inlining might lead to more places where |__builtin_dynamic_object_size| can derive a size and thus more checks, possibly slowing down the code. That might be counterintuitive.
Aaron