libera/#clasp - IRC Chatlog
Search
19:15:47
drmeister
Then we shouldn’t be invoking continue_unwinding because the destination was already past.
19:27:31
yitzi
drmeister: I've succeeded in merging the cclasp and eclasp fasl folders. No more need for names like `SRC:LIB;ECLASP-BITCODE-BLA;` ... and eclasp reuses the fasos from the cclasp image. 400 less file compilations.
20:47:42
drmeister
Do you have any recommendations for additional debugging info? Can we trace entry into sjlj_unwind and leaving setjmp to try/catch?
21:09:39
Bike
it sounds like the problem is unwinding past where we should be, so i guess it would make sense to trace entry into sjlj_unwind_proceed and figure out whether the destination is actually live when we start each sub-exit
22:06:47
drmeister
Yes and yes - but I’m afk at the moment. I posted details above. When I get back to my computer if you are up for it we could try figuring this out together.
22:08:01
drmeister
I’ve added debugging tools that will help sort it out. We can now dump the dynenv stack and it shows where in the regular stack unwinding goes to.
22:11:26
Bike
hm, maybe it's just unwinding through tpl because tpl is used for the debug repl, though
2:41:07
drmeister
This is a problem with bytecode - not cclasp. It happens when I load everything as bytecode - but not when I run it in cclasp.