Re: [PATCH 00/46] gcc-LTO support for the kernel

[Ard Biesheuvel]

On Thu, 17 Nov 2022 at 14:55, Richard Biener <rguenther@xxxxxxx> wrote:
>
> On Thu, 17 Nov 2022, Ard Biesheuvel wrote:
>
...
> > We have an __ADDRESSABLE() macro and asmlinkage modifier to annotate
> > symbols that may appear to the compiler as though they are never
> > referenced.
> >
> > Would it be possible to repurpose those so that the LTO code knows
> > which symbols it must not remove?
>
> I find
>
> /*
>  * Force the compiler to emit 'sym' as a symbol, so that we can reference
>  * it from inline assembler. Necessary in case 'sym' could be inlined
>  * otherwise, or eliminated entirely due to lack of references that are
>  * visible to the compiler.
>  */
> #define ___ADDRESSABLE(sym, __attrs) \
>         static void * __used __attrs \
>                 __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
> #define __ADDRESSABLE(sym) \
>         ___ADDRESSABLE(sym, __section(".discard.addressable"))
>
> that should be enough to force LTO keeping 'sym' - unless there's
> a linker script that discards .discard.addressable which I fear LTO
> will notice, losing the effect.  A more direct way would be to attach
> __used to 'sym' directly.  __ADDRESSABLE doesn't seem to be used
> directly but instead I see cases like
>
> #define __define_initcall_stub(__stub, fn)                      \
>         int __init __stub(void);                                \
>         int __init __stub(void)                                 \
>         {                                                       \
>                 return fn();                                    \
>         }                                                       \
>         __ADDRESSABLE(__stub)
>
> where one could have added __used to the __stub prototypes instead?
>

Probably, yes.

But my point was not really about the implementation of those things,
more about whether we could redefine them to something else that would
help the compiler infer that this symbol needs to be retained.

asmlinkage in particular seems relevant, which is currently only used
for C++ inclusion or for setting regparm{0} on i386.