Hello everyone! This report covers the span of the last two weeks of my porting efforts to get swift running on Haiku. I started debugging the runtime library ‘libswiftCore’ on both Haiku and Linux and focused my attention specifically to the ImageInspection logic in order to fully understand how the runtime extracts ‘type metadata’ from a swift generated shared object. My mentor korli, recommended me to use the get_next_image_info() function, which is the Haiku equivalent of iterating through the list of loaded libraries in a executable. Hence this, it was used to implement dl_iterate_phdr() in ImageInspection.cpp, taking some inspiration from the Cygwin port but parts were rewritten to be used on ELF based platforms.
I don’t think it is used directly, but waitpid is used in TaskQueue.inc but the wait4() implementation defined here uses waitpid(); In regards to the strace in ticket #13546 and the one from this gist, are these issues both related to each other?
bugreport #13546 is unrelated to waitpid(). What you need is investigate what the task queued is doing, typically the option -t of strace should trace the forked children.
The description I said about ‘fixing the compiler’ in relation to posix_spawn() was somewhat misleading. After discussing about the strace log on IRC and the mailing lists, I don’t think that posix_spawn() being unimplemented was the main cause for the compiler to loop on poll() and this will be corrected in the next blogpost.
My main motivation for implementing posix_spawn() was to support the subprocessing functionality in swift. We can still use fork() and execve() in the TaskQueue code for now, but I’m sure that posix_spawn() will be widely used in other swift libraries where Haiku must eventually support this soon.
