[GSoC 2017] Porting Swift to Haiku - Week #3
Hello everyone! This is a rather short update on the Swift port and since the last blog post, I've worked around a small issue that prevented the compiler from importing libraries by specifying the -sdk parameter with a ‘/’ which passes the correct header search paths to swiftc. This issue also existed on other platforms such as FreeBSD according to this thread in the swift-dev mailing list . Whilst researching around the frequent swift interpreter crashes when opening a swift source file, the fault lies in libswiftCore being unable to extract type metadata from swift-generated dynamic libraries when calling these functions specified in the ProtocolConformance and Metadata classes. It is also evident that whenever swift attempts to load this metadata at runtime, it uses ‘dl_iterate_phdr()’ to iterate over every ELF object loaded into the process address-space and will initiate a callback that will emit internal ELF information defined in the dl_phdr_info* struct. I will spend this week with my mentors to implement a Haiku replacement for this function.
During the coding period of June, I will be focused on bringing a working swift toolchain to Haiku and afterwards, the newly built toolchain will be put through a series of tests via the built-in test-suite. Also at HaikuPorts, I added thread-local storage support in clang and my mentor (korli) advised me to disable building position-independent executables (PIE) by default. By using llvm-4.0.0-2 from HaikuPorts, I successfully built swift from source and even published a WIP recipe for anyone to try out . (It still cannot build/interpret swift source files yet.)
Over at the Haiku source tree, My patch to ticket #8798 about a missing pthread_rwlock macro wasn't suitable for Haiku's current pthread_rw_lock design. Specifically, the values defined in my PTHREAD_RWLOCK_INITIALIZER patch were incorrect and initialising a rwlock_t variable with them, may cause undefined behaviour (potentially data races) when used later on. For now, this macro has been commented out, until it is properly implemented in Haiku. As for testing the compiler, this isn't possible at the moment as swiftc cannot compile/run a simple hello-world yet. Therefore, I pushed back testing/validation support once a working executable can be generated.
Goals For Next Week
- Implement dl_iterate_phdr() equivalent for Haiku.
- Investigate issues in regards to compilation.
- Refactor swift recipe.
 Swift 3.1 recipe
- No, I'm not Haiku's lead developer
- Haiku monthly activity report - 12/2019
- Haiku almost-monthly activity report - October and November 2019
- Haiku monthly activity report - September 2019
- Node.js now available in Haiku
- Haiku monthly activity report - 08/2019
- GSOC 2019 Final Report
- Haiku Activity Report: Performance Edition
- new PVS studio scan
- Coding week 4,5,6