Prevent bindgen from generating #[derive(Debug)]

[nbdd0121]

Bindgen generates #[derive(Debug)] for all bindings by default.
We never use these, and probably it didn't make sense to use them
at all. But as we currently do not have LTO enabled, and all the
bindings are exported via pub mod bindings, these Debug
implementations take a lot of space.

On my config this saves 400 KB of space:

 text data bss dec hex	filename
6388276	2284324 292872	8965472 88cd60	vmlinux (with `Debug`)
6079475	2200836 292872	8573183 82d0ff	vmlinux (without `Debug`)

Discovered by a tiny static analysis tool that I am writing :)

[ksquirrel]

Review of 211d8ae02986:

• ✔️ Commit 211d8ae: Looks fine!

[wedsonaf]

Nice!

[TheSven73]

What's the reason we don't have LTO enabled? I'm not saying it should be, just curious about the tradeoffs or difficulties regarding LTO.

[bjorn3]

Regular LTO won't work because --emit obj is used and rustc doesn't do the linking. Linker plugin lto would work, but requires a linker plugin for LTO that has the exact same version of LLVM as rustc.

[TheSven73]

Interesting. And the linker (which I'm guessing is gcc's ld?) doesn't have a way to tell which .o objects are unused?

[nbdd0121]

Only one .o file is created per crate.

[TheSven73]

Sorry, I meant the objects inside the .o. Such as functions, global variables, etc.

[nbdd0121]

Well, it's the same as C; without LTO or ffunction-sections + gc-sections, all functions with external linkage will be kept.

[TheSven73]

Ah I see. And there's no simple way have rustc generate function sections? Which are then gc'ed by ld ?

[bjorn3]

That is the default for rustc, but not for linux.

[TheSven73]

Thanks! So you're saying that rustc generates function sections by default, but ld as used by Linux doesn't gc them?

[bjorn3]

The target specs used by rust-for-linux disable function sections completely AFAIK.

[nbdd0121]

Kernel's --gc-sections support is behind config LD_DEAD_CODE_DATA_ELIMINATION which is marked experimental and hidden beind config EXPERT.

[TheSven73]

Very interesting info, thanks! I noticed that the next kernel version (v5.13-rc3) contains optional LLVM LTO support. The defconfig allows us to select LTO or ThinLTO. Only works for arm64 and x86 though.

Is the plan to simply piggy-back onto this, when we move to the next kernel version? Perhaps @ojeda has some insights too?

Edited: ThinLTO worked, although slowly. Full LTO simply exhausted all memory on my 16 gig RAM laptop before it could finish. Holy smoke.

Edit 2: ThinLTO kernel size is actually larger than no LTO kernel size on my builds. Seems like there are a few wrinkles to be ironed out upstream still.

[nbdd0121]

Edit 2: ThinLTO kernel size is actually larger than no LTO kernel size on my builds. Seems like there are a few wrinkles to be ironed out upstream still.

LTO is usually meant for performance improvement rather than size reduction. It could reduce the size if a lot of functions are unused, but obviously that's not the case for kernel's C code.

To be able to LTO rust, you need to add -Clinker-plugin-lto to the flags. This still doesn't allow any functions to be removed though, because they are all exported, so you additionally need CONFIG_TRIM_UNUSED_KSYMS.

[wedsonaf]

Is the plan to simply piggy-back onto this, when we move to the next kernel version? Perhaps @ojeda has some insights too?

FWIW, at Google we enable LTO when building android kernels.

[TheSven73]

FWIW, at Google we enable LTO when building android kernels.

Thanks! Why is this done?

[wedsonaf]

FWIW, at Google we enable LTO when building android kernels.

Thanks! Why is this done?

I wasn't directly involved in the work, but AFAIU, LTO improved performance and binary size. It was also required for control-flow integrity (CFI), which itself degrades performance but this degradation is offset by the improvements brought by LTO.

I can confirm that building the kernel takes longer but we're willing to take the compilation time hit if the resulting binary is faster and/or harder to exploit.

[TheSven73]

I see, that sounds like a good tradeoff.

I'm assuming not all of this stuff made it upstream? Because I noticed that ThinLTO has a bigger binary size compared to no LTO. And FullLTO ate all my laptop's memory :) For v5.13-rc4 targeting arm64 anyway.

[wedsonaf]

I'm assuming not all of this stuff made it upstream? Because I noticed that ThinLTO has a bigger binary size compared to no LTO. And FullLTO ate all my laptop's memory :) For v5.13-rc4 targeting arm64 anyway.

I'm not sure, it could be differences in other configurations too. I know the goal is to have everything upstream but I'm not sure if we're there yet. The kernels are all publicly available though, some details (including link to git repo) are available here:
https://source.android.com/devices/architecture/kernel/generic-kernel-image

[ojeda]

I wasn't directly involved in the work, but AFAIU, LTO improved performance and binary size. It was also required for control-flow integrity (CFI), which itself degrades performance but this degradation is offset by the improvements brought by LTO.

Related: LWN had an article on CFI a few days ago https://lwn.net/Articles/856514/