glue: implement for riscv64

Change-Id: I0d701050e8ee008db68b54d458de07c653a370d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3920
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

runtime_loader: Rework static initialization handling.

Previously, static initializers were just in ".ctors", which was handled
by GCC's crtbeginS, and that was injected in-between crti and crtn. No

runtime_loader: Rework static initialization handling.

Previously, static initializers were just in ".ctors", which was handled
by GCC's crtbeginS, and that was injected in-between crti and crtn. Now,
however, binutils puts static initializers into init_array/fini_array by
default, which runtime_loader handles, but of course as initialize_after and
terminate_after are supposed to be called *after* all static initializers
are called; and since runtime_loader called init_array after _init, they
were not.

Now, we get rid of the __haiku_init_before/etc. functions, and move their
functionality inside runtime_loader. This is a "soft" ABI breakage,
which is mitigated by adding another ABI breakage (runtime_loader now
returns NULL for the initialize_before/etc. symbols, as otherwise
old applications would have their initialize_before/etc. called twice;
once by runtime_loader, and then once by __haiku_init_before/etc.)

I don't see or know of any reason why an application would want to
get those symbols at runtime, though, so this shouldn't have any
adverse effects.

Change-Id: I42344c63f69c6f8ef260f6c3ca30202b6dfb153e
Reviewed-on: https://review.haiku-os.org/c/907
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

show more ...

system/glue: Get your arm outta my risc!

Change-Id: Ie000430275df9be5568d7d8e330743120691ac4f

riscv32/64: Stub out some core architecture code

Change-Id: I437dff816e87ec5692cca0aaacaada27b43089ee