On Tue, Nov 15, 2022 at 10:38 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > > > Stanislav Fomichev <sdf@xxxxxxxxxx> writes: > > > > > - drop __randomize_layout > > > > > > Not sure it's possible to sanely expose it via UAPI. Because every > > > .o potentially gets its own randomized layout, test_progs > > > refuses to link. > > > > So this won't work if the struct is in a kernel-supplied UAPI header > > (which would include the __randomize_layout tag). But if it's *not* in a > > UAPI header it should still be included in a stable form (i.e., without > > the randomize tag) in vmlinux.h, right? Which would be the point: > > consumers would be forced to read it from there and do CO-RE on it... > > So you're suggesting something like the following in the uapi header? > > #ifndef __KERNEL__ > #define __randomize_layout > #endif > 1. __randomize_layout in uapi header makes no sense. 2. It's supported by gcc plugin and afaik that plugin is broken vs debug info, so dwarf is broken, hence BTF is broken too, and CO-RE doesn't work on kernels compiled with that gcc plugin.
