LWDR SAOC Milestone 1, Weekly Report for 29th SEP to 6th OCT

[Dylan Graham]

[Source Code](https://github.com/hmmdyl/LWDR)
[Plan](https://github.com/hmmdyl/SAoC2021/blob/main/plan.md)
[Proposal](https://github.com/hmmdyl/SAoC2021/blob/main/proposal.md)
[SAOC 
Projects](https://dlang.org/blog/2021/08/30/saoc-2021-projects/)

[Report for week 1 of milestone 
1](https://forum.dlang.org/thread/vodbtqqwvdmapnjzlzaq@forum.dlang.org)
[Report for week 2 of milestone 
1](https://forum.dlang.org/thread/sqounqxhveqhbcxcmxbw@forum.dlang.org)

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](https://github.com/hmmdyl/LWDR/commit/31278fab8bba5120e0cd0ee871d11b9675409bc9). 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`](https://github.com/dlang/druntime/blob/stable/src/rt/minfo.d) more carefully. I found a reliance on something called `HashTab`. I have implemented a data structure called the [`LLUnionSet`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/lwdr/internal/unionset.d), 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`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/moduleinfo.d).

I have replicated [DRuntime's 
`core.internal.array.casting.__ArrayCast`](https://github.com/dlang/druntime/blob/stable/src/core/internal/array/casting.d#L75) in [LWDR](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/arrcast.d), as some code in LWDR needed it.

All hardware implementations for getting the module information 
now have to provide a [function called 
`allModules`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/sections/ldc.d#L18), which returns a range over all modules present. For now, only the implementation for 'exotic' platforms compiled with LDC are supported. The [TLS](https://github.com/hmmdyl/LWDR/tree/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/tls) and [section/module information](https://github.com/hmmdyl/LWDR/tree/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/sections) 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](https://github.com/dlang/druntime/blob/stable/src/rt/minfo.d#L165) was [reimplemented](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/rt/moduleinfo.d#L37). 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`](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/lwdr/package.d#71) 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](https://github.com/hmmdyl/LWDR/blob/f641dde3f36a2b01216cad2c279173304386f35b/source/core/bitop.d), 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](https://github.com/hmmdyl/LWDR/wiki/Thread-Local-Storage#register-clobbering-on-arm-eabi).

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