freenode/#clasp - IRC Chatlog
Search
19:11:42
Bike
well, it works perfectly, but i guess there's no guarantee an out of extent return might accidentally hit a frame, so we'd also want a counter of some kind
22:54:17
Bike
so about unwinding: right now what we do is when we hit a catch-instruction, we make a cons to distinguish the frame
22:54:48
Bike
i tried having it use llvm.frameaddress aka __builtin_frame_address aka RBP instead, and that works, but for out of extent returns it might be ambiguous so we'd need a counter or something in there too
22:55:41
Bike
if we do that, we can use libunwind to interrogate the RBP of each frame, and so i put something together that can note out of extent returns and do something nicer than crashing
22:55:57
Bike
this makes unwinding slower, because we then interrogate the stack three times, instead of just twice
0:55:25
Bike
the itanium abi is reasonable but the C++ one is... way more complex than we need for lisp
0:58:48
Bike
because you could hypothetically have a new, unrelated stack frame that happens to have the same frame pointer
1:00:43
Bike
then two separately established frames would be distinguished by having different integers
1:01:34
Bike
anywho, i think we could set up a personality routine that uses our rules to determine whether a frame is where we're exiting to, instead of C++'s like we do now
1:01:52
Bike
so it would just check that it's one of our exceptions and not C++'s, and if so, compare the frame pointer and this counter, and that's it
1:06:48
Bike
In C++ you can have like, "} catch (foo x) { ... throw x; ... }" so the exception has to stick around, and the unwind machinery has to be prepared for that
1:07:26
Bike
we have it NOW, but only because if we have a dynamic block it does a C++ catch for EVERY unwind, even if it's just passing through
1:18:54
Bike
anyway first i'll merge what i have (with fpe disabled), it handles a few more signals more nicely