Remove reliance on static initializers for registration

delroth commented

2024-05-29 12:50:49 +00:00

Member

A few places in Lix rely on static initializers to register various ops or backends. This is generally a bad idea: static initializers have undefined execution ordering which can vary across builds or even sometimes across runs, they break inter-module dependency analysis which can lead to really weird behavior with static .a builds, they break a whole bunch of static analysis / unused code detection, etc.

They also happen to be global and impossible to be made not-global, which could impair plans for a better liblix.

Let's instead switch to explicit registration of those ops / backends / ... as part of an "init" function/method. This will keep them as global for now - this proposed change is neutral on that dimension. The old Register* structs used for static initializer registration will be kept in the short term as __attribute__((deprecated))for plugin compatibility, but this might be revisited if we decide not to care about plugin source compatibility.

Known places to update:

RegisterLegacyCommand
RegisterCommand
GlobalConfig::Register
RegisterStoreImplementation (cl/1385)
RegisterPrimOp

A few places in Lix rely on static initializers to register various ops or backends. This is generally a bad idea: static initializers have undefined execution ordering which can vary across builds or even sometimes across runs, they break inter-module dependency analysis which can lead to really weird behavior with static .a builds, they break a whole bunch of static analysis / unused code detection, etc. They also happen to be global and impossible to be made not-global, which could impair plans for a better liblix. Let's instead switch to explicit registration of those ops / backends / ... as part of an "init" function/method. This will keep them as global for now - this proposed change is neutral on that dimension. The old `Register*` structs used for static initializer registration will be kept in the short term as `__attribute__((deprecated))`for plugin compatibility, but this might be revisited if we decide not to care about plugin source compatibility. Known places to update: - [ ] RegisterLegacyCommand - [ ] RegisterCommand - [ ] GlobalConfig::Register - [ ] RegisterStoreImplementation (cl/1385) - [ ] RegisterPrimOp

❤️ 2

delroth referenced this issue

2024-05-29 12:51:41 +00:00

Static builds fail #306

delroth referenced this issue

2024-05-29 12:52:21 +00:00

Split up `primops.cc` #42

tom-hubrecht referenced this issue

2024-05-29 14:17:01 +00:00

Split up `primops.cc` #42

delroth referenced this issue

2024-05-29 14:18:22 +00:00

Split up `primops.cc` #42

tom-hubrecht commented

2024-05-29 20:36:10 +00:00

The beginning for RegisterPrimOp removal is at https://gerrit.lix.systems/c/lix/+/1342

The beginning for `RegisterPrimOp` removal is at https://gerrit.lix.systems/c/lix/+/1342

jade added the

stability

label 2024-05-30 07:11:49 +00:00

qyriad referenced this issue

2024-06-01 04:08:35 +00:00

global variables and static initializers that log are not sound #368

lix-project referenced this issue from a commit

2024-06-01 19:17:37 +00:00

build: fix static linking with a hack

delroth commented

2024-06-05 03:35:35 +00:00

Author

Member

Of the cases I've listed, I think GlobalConfig::Register will likely be the thorniest. It's being used across shared libraries, which means it's really not trivial to invert the dependency without introducing loops. Most likely it will need a fairly major refactor of the initialization API for all the sub libs in Lix.

The other ones seem self contained to a single shared module so they should be easier.

Of the cases I've listed, I think `GlobalConfig::Register` will likely be the thorniest. It's being used across shared libraries, which means it's really not trivial to invert the dependency without introducing loops. Most likely it will need a fairly major refactor of the initialization API for all the sub libs in Lix. The other ones seem self contained to a single shared module so they should be easier.

delroth commented

2024-06-05 04:04:35 +00:00

Author

Member

cl/1385 should take care of RegisterStoreImplementation

cl/1385 should take care of `RegisterStoreImplementation`

lix-bot commented

2024-06-10 22:43:50 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1385 ("libstore: remove static initializers for Store registrations")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1385](https://gerrit.lix.systems/c/lix/+/1385) ("libstore: remove static initializers for Store registrations")

Remove reliance on static initializers for registration #359