actions called on the host are done under the AROS task's stack

[Kalamatee]

On hosted, AROS uses signals to alter the host processes hardware context, so that the currently running AROS tasks stack/PC, etc, is used.

The problem is drivers, or any other code that calls functions on the host OS, do not switch out the AROS tasks stack when performing the operations and so call code written for the host operating system still with the running AROS tasks stack used. Since the host does not know how to work with our stack, undesirable things can occur.

HostGL is a prime example. Depending on the GL driver the host is actually using, either unpredictable behavior occurs or memory gets trashed in AROS due to functions using more stack than AROS provides.

[Kalamatee]

I would propose the following change(s) to address this -:

during startup on hosted, when the boot process is created, the host stack should be switched out (if it is not already) but we should store it to switch back in when appropriate.

"AROS" code should not directly call host functions, but instead the kernel should provide a syscall or similar that takes a callback to be performed in the context of the host process. When called it will switch the hosts stack back in, and call the requested callback. Upon completion it should return to the calling AROS task where it had left off.

[Kalamatee]

I believe it is also the source of these "warnings" that are shown when AROS boots on hosted -:

[hostlib:unix] Opening 'libXcursor.so.1' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". warning: Corrupted shared library list: 0x555555768650 != 0x7ffff7ffd9f0 [hostlib:unix] opened @ 0x0x555555762490

[hostlib:unix] Opening 'libXxf86vm.so.1' warning: Corrupted shared library list: 0x5555557bab30 != 0x555555768650 warning: Corrupted shared library list: 0x5555557bab30 != 0x555555768650 [hostlib:unix] opened @ 0x0x555555769100

0x7ffff7ffd9f0 appears to be in the host process stack, while all the other addresses are within the memory that has been allocated for AROS.

[thatguywiththekids]

Is there anything left to do here?

[Kalamatee]

Yes.. some mechanism needs implemented to interface between the host task when it's running in the context of AROS, and when AROS calls host functionality. All existing drivers, etc, doing this would need adapted.