Stream: general

Topic: Padding and niches


RalfJ (Mar 19 2020 at 21:32, on Zulip):

So reading this made me wonder about padding and niches again... I wonder if it would make sense to add a repr attribute that basically says "for this type, instead of padding with arbitrary bytes, please pad with guaranteed zero bytes". So basically, the compiler adds padding fields of appropriate size that only have a single valid value, 0x00. That would have the downside that these bytes must be copied when the struct is copied (unlike padding), but it also means that space could be used for niche optimizations.

@eddyb probably already opened an issue for doing this 3 years ago, but at least I haven't seen it. ;)

RalfJ (Mar 19 2020 at 21:33, on Zulip):

I think this is also the direction these comments take

eddyb (Mar 19 2020 at 21:56, on Zulip):

I have not, I don't think

eddyb (Mar 19 2020 at 21:56, on Zulip):

That would have the downside that these bytes must be copied when the struct is copied (unlike padding)

note that this is only a thing for non-Aggregate ABI structs

eddyb (Mar 19 2020 at 21:57, on Zulip):

LLVM doesn't know about padding in our structs, it has no mechanism through which to indicate them (other then maybe first-class aggregates but we stopped using those except for pair return values)

eddyb (Mar 19 2020 at 22:00, on Zulip):

the only change I could see being needed is SetDiscriminant zeroing out the padding (although it would really only need to zero out the niche, optimization-wise :P)

eddyb (Mar 19 2020 at 22:01, on Zulip):

then again such a layout would offer multiple niches if applied to enums

eddyb (Mar 19 2020 at 22:01, on Zulip):

but we gave up on using multiple niches because we expected we'd never zero out padding by default and didn't think of the opt-in, so it would take more effort now

RalfJ (Mar 21 2020 at 07:37, on Zulip):

I see. So should I open a new issue for this, or is there some general niche-related issue I could add this to?

RalfJ (Mar 21 2020 at 15:34, on Zulip):

I opened an issue: https://github.com/rust-lang/rust/issues/70230

tilpner (Mar 25 2020 at 20:37, on Zulip):

Another usecase that could benefit from guaranteed-initialised padding are eBPF programs inside the Linux kernel.
They are being statically verified, to ensure that no uninitialised memory reaches "foreign" functions.

It is currently tricky to pass Rust structs and enums to other Rust programs through these "foreign" functions, because the verifier
notices that e.g. Option<u32> contains uninitialised padding. It is sometimes possible to work around this, by manually zeroing a struct/enum,
and then setting its fields directly, without copying over the padding, but that is unergonomic.

RalfJ (Mar 26 2020 at 08:33, on Zulip):

@tilpner so... the Rust program is compiled to eBPF, and then that program is statically verified by the kernel in certain ways? that's interesting, is that analysis described in detail somewhere?

Laurențiu Nicola (Mar 26 2020 at 11:30, on Zulip):

https://lwn.net/Articles/740157/, https://github.com/torvalds/linux/blob/master/Documentation/networking/filter.txt

RalfJ (Mar 28 2020 at 09:13, on Zulip):

that seems to mostly be about uninitialized "registers", so compiling Rust to eBPF ends up putting enums directly in registers?

Last update: May 29 2020 at 17:45UTC