John Ripleyjripley@mastodon.social
Sep 30, 2026, 5:05 PMWell, that was a whole bunch of debug just to discover the Zephyr calls driver init functions before it calls C++ static constructors. Infinite sigh.
Replies
- John Ripleyjripley@mastodon.socialSep 30, 2026, 5:11 PM
It is apparently a deliberate design choice in Zephyr that C++ static constructors are called _after_ kernel and driver init, so you can essentially only safely use C++ in "application code".
I can say with 100% certainty this is the wrong choice.
About ready to give up on this shit.
- John Ripleyjripley@mastodon.socialSep 30, 2026, 5:13 PM
It strikes me that the reason I'm running into all these basic quality of life (and C++ support) issues, is related to my previous comment about how all the C-based RTOS out there have _suspiciously similar code_. They're all written by the same people, or cross-pollinated by people who moved between places.
The last few RTOS I've worked on were internal, and I (eventually) won battles to make this shit work.
I haven't done that here, and I'm not going to invest in a slop repository.
- John Ripleyjripley@mastodon.socialSep 30, 2026, 5:22 PM
TL;DR reason why late C++ static constructor invocation is dumb:
struct Foo {
device *dev = nullptr;
int thing = 1234;
};
Foo instances[] = { macro hell to initialize dev and thing from device tree };Doesn't even need the keyword "class". With sufficient complexity, the compiler ends of generating an out-of-line static constructor for each instance. So when you go "instance[0].thing" during driver init, you find it is *uninitialized* (zero).
Essentially doesn't support C++.
- John Ripleyjripley@mastodon.socialSep 30, 2026, 5:24 PM
Yes, it is *documented* as saying exactly this, but seriously you could just as easily flip the initialization order, and *document* that you can't call Zephyr APIs from C++ static constructors.
Yes, that would be a mess too, but less of a mess than utterly breaking ABI.