Ghost Kernel

C++ runtime & thread-local storage support 2020/01/28, 18:44:12

With the latest commits, C++ runtime features (most notably exceptions) and thread-local storage are now supported in executables and shared libraries.

The toolchain build was modified so that the shared version of libgcc is now built. Using -shared-libgcc as a linker flag will now cause libgcc to be linked dynamically and therefore allow exception handling over multiple shared objects.

I've adapted the test suite to now call a runtime test program that performs multiple tests for global constructors, exception handling and TLS.

With those additions, shared library support should now be sufficient to continue work on other parts, most notably inter-process messaging will next be implemented in the new kernel implementation.


Shared library support added 2020/01/18, 20:05:33

I've finally implemented basic support for shared library objects in the kernel's elf32 loader. This can be found in the branch dynamic-linking.

The main motivation for this was improving the size of executables and as a preparation for future performance improvements. The current implementation always binds all symbols early (so it behaves as if LD_BIND_NOW was set), so lazy-linking is not yet in use.

With this change, the build processes of libc, libghostapi and libuser where also adapted so they additionally emit .so files. By default the system libraries libc and libghostapi will therefore now be linked shared. The "cocorun" demo program is used to test out various features now.

The next steps are getting support for thread-local storage when such a variable is provided or accessed by a shared library. In the existing implementation, the TLS segment of the main object is loaded and a copy of that TLS master is assigned to each thread. There is some work left to do when working with shared libraries now, because each loaded ELF object can have a TLS segment and TLS relocations which must be fulfilled. For this the process structure must be adapted so that all of this information can be stored and evaluated later on.

Anyway, not much to see but have a look at this nice little shared library call :-)


Threaded system calls & kernel-privilege thread support added 2019/03/04, 16:38:10

The redux branch has now support for kernel-level threads and threaded system calls. The previous implementation only supported userspace-threads which had some advantages but also made specific call implementations more complicated. This approach will improve efficiency and allows a better scheduling implementation in the long run.

There were some interesting problems to solve; due to the fact that a kernel thread might get interrupt while holding a kernel lock, the g_mutex implementation must now keep track of the number of locks held per processor. As long as a task holds kernel locks, no other task will be scheduled until the task is finished with its work.

System calls can now be registered as threaded or direct calls. When a threaded call is executed, the respective handler is called within a kernel-level thread. These processing tasks are reused for successive system calls by the same task. This allows preemption during call processing and avoids blocking the scheduler for long-running requests.


Documentation available 2019/02/24, 11:00:18

The documentation can now be found here. It will be regularly updated from the GitHub repository.

Some parts where already updated to match the redux branch, but some parts are also mostly relevant for the existing code.

If you are interested in building Ghost by yourself, there are now instructions available.


Started redux 2019/02/23, 13:18:34

Updated to binutils 2.31 and gcc 8.2.0. With this branch I've finally started what I planned for a longer time - doing a bigger refactoring of the codebase.

The main focus will be rewriting the taskign implementation. In my initial plan I thought it would be feasible to implement syscall-logic that takes some time within waiter structures. These waiters got pretty complex by now and I feel it makes more sense to use actual kernel threads for some tasks.

You can follow the progress on the redux branch on GitHub.

I've also updated the documentation on how to build Ghost on your local machine - I'm working on getting it on this website soon.