start code: implement __init_array_start, __init_array_end

[andrewrk]

Tested by observing __sanitizer_cov_8bit_counters_init and __sanitizer_cov_pcs_init being called in a libc-less build.

[alexrp]

I would suggest also splitting up the calls to callMainWithArgs() and std.posix.exit() here, and calling the function pointers stored between __fini_array_start/__fini_array_end.

[andrewrk]

@Rexicon226 how are we feeling about @divExact?

[andrewrk]

I would suggest also splitting up the calls to callMainWithArgs() and std.posix.exit() here, and calling the function pointers stored between __fini_array_start/__fini_array_end.

hmmm I don't know about that. I like it better when the process just ends. The OS cleans up all the memory and open handles, and any resource not cleaned up by the OS is a bug because the process could have been terminated abnormally. Not implementing those destructors forces people to code correctly.

[alexrp]

hmmm I don't know about that. I like it better when the process just ends. The OS cleans up all the memory and open handles, and any resource not cleaned up by the OS is a bug because the process could have been terminated abnormally. Not implementing those destructors forces people to code correctly.

It's needed for correctness in some cases though. If I build some C code that uses __attribute__((destructor)) for cleanup into a Zig program that doesn't link libc, those destructors just won't be called. For an example of why this might actually matter for more than just simple handle cleanup, see #20382. Actually, you know what, that one's a bad example because it's about shared libraries primarily. The general point still stands about arbitrary C code, though. Agree it's not a concern for pure Zig code.

[jacobly0]

I would suggest also splitting up the calls to callMainWithArgs() and std.posix.exit() here, and calling the function pointers stored between __fini_array_start/__fini_array_end.

hmmm I don't know about that. I like it better when the process just ends. The OS cleans up all the memory and open handles, and any resource not cleaned up by the OS is a bug because the process could have been terminated abnormally. Not implementing those destructors forces people to code correctly.

I'd argue that "not running destructors" should be the behavior of std.process.cleanExit in release modes, not the default. In fact, if handling is added between callMainWithArgs and std.posix.exit as was suggested, this would already be the case since cleanExit calls exit itself in release modes, instead of returning from main.

As for there being no use case for destructors, the first one that occurs to me is flushing compiler instrumentation data to disk for non-fuzzing use cases. In this case, it may be desirable to not write misleading profiling data when the process exits abnormally, maybe because you just got the command line syntax wrong the first time.

That said, I don't think there should be explicit language/std support for defining destructors in Zig, that use case seems questionable and the friction should remain with creating them from Zig.

[andrewrk]

For that use case specifically, you would expect the executable to exit(1) (as opposed to trapping) on an invalid command line syntax right? Are you suggesting to not run the destructors if the exit code is nonzero?

[jacobly0]

Yeah I forgot that calling std.posix.exit calls the destructors when linking libc, not sure how much of a use case there is when you aren't depending on C libraries. In any case, maybe having them both in std.options but disabled by default is the way to go.

[andrewrk]

That seems reasonable. It's enough friction to satisfy me.