Messages in this thread | | | Date | Thu, 17 Nov 2022 15:32:33 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 00/46] gcc-LTO support for the kernel |
| |
On Thu, Nov 17, 2022 at 01:55:07PM +0000, Richard Biener wrote:
> > > I'm not sure what you're on about; only symbols annotated with > > > EXPORT_SYMBOL*() are accessible from modules (aka DSOs) and those will > > > have their address taken. You can feely eliminate any unused symbol. > > But IIRC that's not reflected on the ELF level by making EXPORT_SYMBOL*() > symbols public and the rest hidden - instead all symbols global in the C TUs > will become public and the module dynamic loader details are hidden from > GCCs view of the kernel image as ELF relocatable object.
It is reflected by keeping their address in __ksymtab_$foo sections, as such their address 'escapes'.
> > 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.
The initial LTO link pass will not discard .discard sections in order to generate a regular ELF object file. This object file is then fed to objtool and the kallsyms tool and eventually linked with the linker script in a multi-stage link pass.
Also see scripts/link-vmlinux.sh for all the horrible details.
> The folks who worked on LTO enablement of the kernel should know the > real issue better - I understand asm()s are a pain because GCC > refuses to parse the assembler string heuristically for used > symbols (but it can never be more than heuristics).
I don't understand why it can't be more than heuristics; eventually the asm() contents end up in a real assembler and it has to make sense.
Might as well parse it directly -- isn't that what clang-ias does?
> The issue with asm()s is not so much elimination (__used solves that) > but that GCC can end up moving the asm() and the refered to symbols to > different link-time units causing unresolved symbols for non-global > symbols. -fno-toplevel-reorder should fix that at some cost.
I thought the whole point of LTO was that there was only a single link time unit, translate all the tus into intermadiate gunk and then collect the whole lot in one go.
| |