On Tue, Feb 24, 2026 at 10:53 AM Jakub Kicinski <[email protected]> wrote: > > On Tue, 24 Feb 2026 10:43:15 +0800 sun jian wrote: > > > Constructors seem to have a concept of priority so if we have to, > > > we should probably used those for the fix. > > > > I considered constructor priorities, but I'd prefer to avoid relying on > > toolchain/linker specific init ordering here. > > I thought constructor priorities were specifically created to avoid the > problem you are seeing. What it is the point of constructor priorities > if not to order constructors?? You're right that ctor priorities exist to order constructors.
With clang+lld (LLVM=1) I can reproduce xfail nodes being attached to variant->xfails but with xfail->test == NULL, so the pointer wasn't available at XFAIL_ADD() registration time. I don't object to ctor priorities per se. My concern is that fixing this via priorities likely requires ordering the entire registration chain, not just XFAIL_ADD(): kselftest_harness.h has multiple constructor-based registration sites (I see at least 5 macro-generated ctor blocks plus the constructor-order helper), so we'd need to thread and maintain explicit priorities across the relevant registration macros to guarantee that the test/fixture/variant metadata is fully registered before XFAIL_ADD() runs. To avoid relying on init order, I'm happy to send a v2 which doesn't add new state and doesn't rely on ctor ordering: keep xfail->test as a cached pointer, but resolve it lazily at runtime on first use by looking up the test metadata by name within the fixture's test list, then use the original pointer match thereafter. This resolution happens at most once per xfail entry and keeps the hot path pointer-based. If you prefer ctor priorities, I'm also happy to respin that way — but I'd appreciate guidance on which ctor(s)/registration macros you want ordered against XFAIL_ADD() so we can keep the change minimal. Thanks, sun jian
