freenode/#clasp - IRC Chatlog
Search
8:42:57
Younder
A bit late but are you familiar with Valgrind? http://valgrind.org/ It can usually track down problems that defeat other tools in debugging, but is is slow work.
18:06:32
stassats
when scraping, WARNING: redefining PRINT-OBJECT (#<STANDARD-CLASS COMMON-LISP:STANDARD-OBJECT> #<SB-PCL:SYSTEM-CLASS COMMON-LISP:T>) in DEFMETHOD
18:06:33
drmeister
I'm wrestling with exception handling problems that have come about because of the changes.
18:38:31
drmeister
I used to let RAII handle cleaning up things that I now need to handle explicitly
18:39:35
drmeister
This means using invoke in place of call in certain places. I had a call where I needed an invoke so that debugging info was cleaned up on function exit
18:40:45
frgo
I vaguely remember understanding the difference between call and invoke - but I am missing it now.
18:41:59
drmeister
If a function has cleanup code and you use call and the called function unwinds the stack then the cleanup will be skipped.
18:43:47
drmeister
It's a pita to even identify where it's happening and what is happening. I suspected stack corruption for days and wasted a lot of time.
19:21:36
drmeister
Do you recall how to get the owner of an instruction - the enter instruction some other instruction belongs to?
19:22:40
drmeister
I've got an instruction in translate-simple-instruction - I need to know the owner of it.
19:27:28
drmeister
The problem that I wrestled with the last week is exception handling and CALL vs INVOKE for calling functions.
19:28:28
drmeister
So right now if a function can be the target of an UNWIND instruction, that function gets set up differently than a function that is not the target of an UNWIND instruction.
19:29:29
drmeister
Functions that are targets of UNWIND have any CALL to a function that can unwind the stack converted to an INVOKE.
19:30:24
Bike
what if there's an intermediate? like you have functions f1 f2 f3, f1 calls f2 and f2 calls f3, and f3 unwinds into f1?
19:31:39
drmeister
The INVOKE invocations get a thing called a 'landing-pad' attached to them. The 'landing-pad' is a place in the function that checks the C++ exception (stack unwinding) that is coming in to see if this function is the target of that exception and if so - it dispatches into the function and if not it rethrows the exception for a function higher up.
19:32:21
drmeister
If there are intermediates f1 f2 f3 and f3 unwinds to f1 then f2 doesn't need INVOKE or landing-pads.
19:33:15
drmeister
This works because Common Lisp generated functions don't have any cleanup that they need to do when they exit.
19:33:38
drmeister
UNWIND-PROTECT is handled by a C++ function that you pass a protected function and a cleanup function.
19:36:08
drmeister
Lambda list handling code can signal errors - but if those errors lead to stack unwinding - they are not caught by the function within which the lambda list processing error occurred.
19:37:07
Bike
Um... guess not. It's not like you can install a handler for a &key misparse in the body of the function doing the parsing.
19:37:23
drmeister
My question is coming out of the blue - so it's ok if not. I'm not trying to put you on the spot. Just trying to check my thinking and say this aloud so I think about it.
19:38:40
drmeister
Currently the HIR/MIR don't contain anything that represents the lambda list processing code. It's generated as llvm-ir when the enter-instruction is translated.
19:39:54
drmeister
Now, functions are called directly. I can't use DWARF because DWARF is too hard for me to tackle right now.
19:40:45
drmeister
So I'm going back to my approach of pushing a InvocationHistoryFrame onto the stack when a function that is compiled with DEBUG=3 on is entered and popping it from the stack when the function is exited.
19:41:13
drmeister
This means cleanup information needs to be installed for functions that have DEBUG=3.