When in debug mode, perform type-safety checks on stack frames #22
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: simon/post-scarcity#22
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently we're mostly compiling with
as a compile-time option.
Passing everything around as
pso_pointersbypasses even C's rather lax type safety. Of course this doesn't matter for code written in Lisp, because it is the compiler's responsibility to mechanically make sure that only stack frames are passed into functions as stack frames. But if something else was passed in as a stack frame, the results probably wouldn't be pretty, and at least while I'm mostly running boostrap functions hand written in C, there is a risk.Type checking the stack frame every time a function is entered is an overhead that will grow big quickly. I'm inclined to not do it in production. But I think it's essential to do it during debugging.
Proposal:
DEBUG = TRUEis by default set but which can also be set by the invocation-time-dflag;node.c/node.hand is visible to C code, but is optionally also visible to Lisp code;make_frame,fetch_argandfetch_envwill type-check the stack pointer and throw an exception if the thing it points to isn't actually a stack frame.I would like to make it rebindable in Lisp, but the standard way of doing that (i.e. binding it in the execute time environment) won't work because that binding is in the environment, which is in the stack frame, which if what you've been passed isn't a real stack frame you won't have.
It would be possible to bind it somewhere else — possibly on
::system:users:user:home/debug(which could only affect the user's home node, I think), or on::system:mesh/debug(which would affect all nodes in the hypercube, but only a user with:systemprivilege could set); but really that isn't a problem for now.