Override assert handler

[Richard (Rikki) Andrew Cattermole]

On 18/08/2024 1:53 PM, Walter Bright wrote:
> Allow me to explain how a library works.
> 
> The linker resolves all the symbols in the object files given to it. 
> When there are references to symbols, but no symbols, then (and only 
> then) does the linker consult the library. The linker will pull in 
> modules from the library that export those missing symbols.
> 
> Therefore, the easiest way to override a function that's in the library 
> is to write your own and put it in the list of object files for the 
> linker to incorporate.

This needs some context.

It only applies to object files and executables, the moment shared 
libraries enter the picture (such as druntime) this no longer is the 
full story.

Once shared libraries enter, you have to consult the image loader as 
well. If you have a symbol that overrides another it is first come first 
served and loading is dependency aware.

If the process has been up for a month already, a replacement symbol 
will not replace the existing one. It isn't safe. The loader would 
effectively have the ability to unmap a currently executing function. 
Needless to say that is a bad thing to do on loading of a binary.

> Unfortunately, some early work done on druntime was not aware of this, 
> and so the assert handler is set up as a pointer to a function, with 
> another function to call to set that pointer to your own function.

Unfortunately there is a broader context, and it is my belief that this 
was the correct solution. It works in more situations and still allows 
you via ldc's ``@weak`` (see Martin's reply) to replace the initializer 
during initial link.

> By the time I noticed that, it was too late to fix it.
> 
> I have spent nearly the entire time I've been working on compilers 
> trying and failing to explain how linkers work.

And now I get to explain how loaders work ;)