On Thu, Mar 25, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Thu, Mar 25, 2021 at 03:40:51PM +0100, Richard Biener wrote:
> > I think the "proper" way to do this is to have 'open' above end up
> > refering to the out-of-line 'open' in the DSO, _not_ to emit the
> > fortification wrapper out-of-line. But then, yes, it shouldn't
> > be always-inline then. It should be like the former extern inline
> > extension.
>
> It is extern inline __attribute__((gnu_inline, always_inline, artificial))
> I think. But the always_inline is completely intentional there,
> we don't want the decision whether to inline it or not being done based on
> its size, amount of functions already inlined into the caller before,
> whether the call is cold or hot, etc. It is a matter of security.
> If it is taking address, we want the library routine in that case, sure.
>
> > But we have existing issues with [target] options differing and existing old
> > uses of always_inline (like the fortification wrappers). Adding a new
> > attribute
> > will not fix those issues. Do you propose to not fix them and instead only
> > fix the new general_regs_only always-inline function glibc wants to add?
>
> Yes.
> Basically solve the problem for the fortification wrappers and rdtsc or
> whatever other always inlines don't really require any specific
> target/optimize options.
>
> > IMHO we have to fix the existing always_inline and we need a _new_
> > attribute to get the desired diagnostics on intrinsics. Something
> > like __attribute__((need_target("avx"))) for AVX intrinsics?
>
> Or, if we go this route in addition to adding
> at least a new attributes for the "diagnose taking address without
> direct call", we'd need probably not just that,
> but also pragma way to specify it for a lot of functions together,
> otherwise it would be a maintainance nightmare.
>
How can we move forward with it? I'd like to resolve it in GCC 11.
Thanks.
--
H.J.
