When in debug mode, perform type-safety checks on stack frames #22

Open
opened 2026-04-21 15:04:58 +00:00 by simon · 0 comments
Owner

Currently we're mostly compiling with

DEBUG = TRUE

as a compile-time option.

Passing everything around as pso_pointers bypasses 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:

  1. We have a per-node debug flag, which when DEBUG = TRUE is by default set but which can also be set by the invocation-time -d flag;
  2. The debug flag is defined in node.c/node.h and is visible to C code, but is optionally also visible to Lisp code;
  3. When the debug flag is set, every call to make_frame, fetch_arg and fetch_env will 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 :system privilege could set); but really that isn't a problem for now.

Currently we're mostly compiling with ```makefile DEBUG = TRUE ``` as a compile-time option. Passing everything around as `pso_pointers` bypasses 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: 1. We have a per-node debug flag, which when `DEBUG = TRUE` is by default set but which can also be set by the invocation-time `-d` flag; 2. The debug flag is defined in `node.c/node.h` and is visible to C code, but is *optionally* also visible to Lisp code; 3. When the debug flag is set, every call to `make_frame`, `fetch_arg` and `fetch_env` will 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 `:system` privilege could set); but really that isn't a problem for now.
simon added the
enhancement
label 2026-04-21 15:05:46 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: simon/post-scarcity#22
No description provided.