#
354b60af |
|
26-Jan-2019 |
Augustin Cavalier <waddlesplash@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. 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>
|
#
6a028821 |
|
10-Dec-2017 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
x86 glue code: keep stack aligned. The glue code pushed 12 bytes to the stack, breaking the 16-byte stack alignment requirement. This would be fixed by the main() prologue from gcc, but all "init" and "fini" code (static/global constructors/ destructors) would run with a misaligned stack. This was already fixed for x86_64 in hrev49731. Note that the fix here is slightly different, the pointer is realigned after it is saved to EBP and the function epilogue restores it from EBP, so no changes to crtn.S are needed.
|
#
25dc253d |
|
22-Nov-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Merged weak-symbols branch. * Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp * Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0cd3c003 |
|
26-Jun-2006 |
Axel Dörfler <axeld@pinc-software.de> |
While investigating how our deals with doubled shared libs, I found two issues: * Our glue code was broken after all - it allowed Haiku apps to start under BeOS (and vice versa), but the initialization/termination functions were called with an invalid image ID - on *both* sides! As it turns out, the Be glue code did *something* with %ebx, but certainly didn't put the image ID in there, but just passed it on the stack, as we did before (just in the wrong order...). Therefore, the arch_call_init_term stuff is not necessary. * When unloading add-ons, their termination functions were never called, as the image (for get_image_symbol()) was already made inaccessible, and therefore the symbol couldn't be found. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17928 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
34a95562 |
|
05-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
Made our glue code compatible to BeOS again. IOW executables compiled for Haiku will now run under BeOS as well (as long as they don't use any functions that are not available under R5). The solution is a bit messy, but we have to live with it :-) The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point to its exported structure instead of passing it to the init functions as an argument. (Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15848 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
5af32e75 |
|
13-Apr-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed src/kernel to src/system. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12359 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
25dc253d6ab28ce204fa4de2d3e7a27d167fc817 |
|
22-Nov-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Merged weak-symbols branch. * Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp * Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0cd3c003d10aa80549c405dd6dd2d696daa75409 |
|
26-Jun-2006 |
Axel Dörfler <axeld@pinc-software.de> |
While investigating how our deals with doubled shared libs, I found two issues: * Our glue code was broken after all - it allowed Haiku apps to start under BeOS (and vice versa), but the initialization/termination functions were called with an invalid image ID - on *both* sides! As it turns out, the Be glue code did *something* with %ebx, but certainly didn't put the image ID in there, but just passed it on the stack, as we did before (just in the wrong order...). Therefore, the arch_call_init_term stuff is not necessary. * When unloading add-ons, their termination functions were never called, as the image (for get_image_symbol()) was already made inaccessible, and therefore the symbol couldn't be found. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17928 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
34a9556215f39bb00d4bb6cf2376543aca82436d |
|
05-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
Made our glue code compatible to BeOS again. IOW executables compiled for Haiku will now run under BeOS as well (as long as they don't use any functions that are not available under R5). The solution is a bit messy, but we have to live with it :-) The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point to its exported structure instead of passing it to the init functions as an argument. (Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15848 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
5af32e752606778be5dd7379f319fe43cb3f6b8c |
|
13-Apr-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed src/kernel to src/system. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12359 a95241bf-73f2-0310-859d-f6bbb57e9c96
|