-
Notifications
You must be signed in to change notification settings - Fork 39
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
backend: make dynlib handling target-agnostic (#796)
## Summary Make code generation for `.dynlib` procedure/variable setup target- agnostic and move it to the unified backend processing pipeline. Instead of as part of the *data-init* module operator, loading dynamic libraries and setting up the procedures and variables now happens in the the new *dynlib-init* module operator (which is called directly after the *data-init* operator). This fixes run-time expressions in `.dynlib` pragmas not being subject to destructor injection and removes the last `PNode` side-channel (i.e., AST reaching the code generators through something else than `genProc`). ## Details The C code generator previously created globals for holding the handle of loaded libraries in an ad-hoc way, with the `PLib` associated with the symbol modified to store the generated C name. This same approach is not possible with the unified pipeline, and instead, more of the `TLib` related handling is moved into semantic analysis: - remove the `TLib.generated` field - store a symbol instead of a raw name in `TLib.name` - the symbol for each `PLib` of a module is generated when the module is closed - adjust `PackedLib` and the related load/store logic With this, a `TLib` is no longer modified outside of semantic analysis, and the code generators don't need to introduce ad-hoc globals. The queueing logic in `process` is adjusted to also consider imported `.dynlib` procedures, with them now having dedicated processing. When they're processed, the procedures are announced to `process`'s caller and the loader logic is generated and emitted. The generated loader logic is, apart from being generated as MIR code, stays as it was. One problem is with dynlib variables. How they're represented is left to the code generators, which means that a normal assignment cannot be used to initialize the internal representation. For this reason, a new internal magic (`mAsgnDynlibVar`) that is used for setting up a dynlib procedures/variables is introduced and implemented in `cgen`. Finally, the workarounds regarding dynlib procedures are removed from `cbackend` and `backends` and the everything dynlib-init specific is removed from `cgen`. Reporting dependencies on statically-known dynamic libraries is now handled in `cbackend`. While now theoretically possible, the JS and VM backend still don't support dynlib procedure and variables.
- Loading branch information
Showing
14 changed files
with
306 additions
and
206 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.