Source Code
Plan
Proposal
SAOC Projects
Report for week 1 of milestone 1
Report for week 2 of milestone 1
Light Weight D Runtime.
6th October, 2021.
Symmetry Autumn of Code, Week 3 of Milestone 1.
Hi all,
The past week has been productive. I have finished task 1 of milestone 1 - implementation of static
and shared static
constructors and destructors, crushed a nasty bug in the thread local storage (TLS) implementation and begun to modularise parts of LWDR.
To start, I did some testing with ModuleInfo
list. Mostly just poking around to see how it worked, and did what I expected it would. I have found that I need to cast the function pointers in the ModuleInfo
structure to nothrow
and @nogc
, otherwise they refuse to call. Sadly, my pervasive usage of nothrow
has not saved me - I've had to implement a stub _d_eh_personality
in C regardless. I will begin to remove the nothrow
tags as it can affect code generation.
I studied the code in DRuntime's rt.minfo
more carefully. I found a reliance on something called HashTab
. I have implemented a data structure called the LLUnionSet
, which sort of does the same thing. It's a collection of key-value pairs and is designed specifically for usage in LWDR's rt.moduleinfo
.
I have replicated DRuntime's core.internal.array.casting.__ArrayCast
in LWDR, as some code in LWDR needed it.
All hardware implementations for getting the module information now have to provide a function called allModules
, which returns a range over all modules present. For now, only the implementation for 'exotic' platforms compiled with LDC are supported. The TLS and section/module information implementations have been split up upon hardware and/or compiler lines. This is to prepare LWDR to support more platforms in the future. All modules in each package should implement the same public interface, which will be called by the LWDR
helper class and other parts of LWDR.
The module sorting and cycle checking algorithm in DRuntime's minfo was reimplemented. The algorithm is responsible for ensuring that static constructors and destructors are called in the correct order and detecting cycles. If a cycle is detected, LWDR currently only raises an assertion saying that a cycle was detected. The LWDR
helper class has been updated been updated to sort and run these constructors and destructors. It should work out of the box (with the version LWDR_ModuleCtors
). For those pedantic about memory consumption (version LWDR_ModuleCtors_MinHeap
), it can also free and re-sort/allocate on each call to LWDR.startRuntime/stopRuntime/registerCurrentThread/deregisterCurrentThread
.
core.bitop
was copied into LWDR, since rt.moduleinfo
relies heavily on it. I had to remove a few unnecessary imports to make it compile properly.
I mentioned last week a problem with the TLS implementation. I wasn't sure what it was at first - I thought it was an alignment problem. Some TLS variables were corrupt, some weren't. Some time in the debugger found that the FreeRTOS TLS implementation was clobbering the registers.
Until the 15th, I will be working on task 2 - implementation of Object monitor and synchronisation primitives. If I have spare time I will have LWDR generate cycle path information if it detects a module dependency cycle.
All the best,
Dylan Graham