-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backend: make dynlib handling target-agnostic #796
backend: make dynlib handling target-agnostic #796
Conversation
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, and I really like how it generalized the dynamic library facility. I did leave a soft suggestion.
On a sidenote, I noticed I struggled remembering what forward
did from the mir DSL. It could well just be me, but I'll also consider a better name.
A `TLib` is also used to store `.header` information, and for those instances no global is needed.
That should fix the IC test failures. Previously, without #797, the symbols, and thus the their associated I also fixed a small oversight of mine where a global was also created for
Hm, yeah, I went through a lot of back and forth with the name, but never really arrived at something self-explanatory (which could indicate that the facility itself is the problem).
|
On non-Windows systems, an extra message is echoed on library loading failure.
/merge |
Merge requested by: @zerbina Contents after the first section break of the PR description has been removed and preserved below:
|
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 subjectto 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 withthe 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 semanticanalysis:
TLib.generated
fieldTLib.name
PLib
of a module is generated when the moduleis closed
PackedLib
and the related load/store logicWith 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. Whenthey're processed, the procedures are announced to
process
's callerand 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 dynlibprocedures/variables is introduced and implemented in
cgen
.Finally, the workarounds regarding dynlib procedures are removed from
cbackend
andbackends
and the everything dynlib-init specific isremoved from
cgen
. Reporting dependencies on statically-known dynamiclibraries is now handled in
cbackend
.While now theoretically possible, the JS and VM backend still don't
support dynlib procedure and variables.