freenode/#clasp - IRC Chatlog
Search
20:51:39
Bike
because the exceptions library does all kidns of goofy shit that probably not reentrant
20:52:23
drmeister
sbcl doesn't use C++ exception handling - it may be leaving something in the stack frames to let them unwind out of a signal handler but from everything that I've been told we cannot do this with C++ exception handling.
20:53:16
Bike
i don't really understand why unwinding out of a signal handler in particular is not allowed. longjmp ought to work, i think
20:54:07
Bike
assuming longjmp is reentrant i guess. maybe all the dumb shit stuffed into jmp_bufs makes that hard
21:00:03
drmeister
A signal can happen between any two instructions - right? Is the stack frame that the signal handler sets up able to synchronize with the itanium unwinding machinery.
21:03:07
Bike
my impression was that within a handler you still have, like, a normal stack with frames and everything
21:03:25
Bike
above your handler function is whatever operating system machinery, and then above that is the frame of the function that was running when the signal interrupted
21:07:58
kpoeck
apart from what are discussing, I believe we have 1 more issue. Just try (mod 1 0) in clasp, sometimes, we get the fpe, sometimes clasp hangs with 99,9% cpu in core::clasp_truncate. lldb knows that an exception happens, but handle_fpe is not called.
21:10:43
Bike
"the main problem with unwinding is dlopen and dlclose" i really hate the C++-brain on this topic, man
21:13:17
drmeister
I don't have the mental bandwidth to follow the whole talk - but there may be something about signal handlers in there.
21:21:03
Bike
looking through stack frames and stuff is no problem. so in a lisp-style unwinding setup, unwinding would be no issue, since all the cleanup and destination info is on the stack. on the other hand, getting the corresponding dwarf info from disc/wherever is not signal safe
21:21:30
Bike
i guess if we like, receive a signal in the middle of dl_iterate_phdr, or something weird like that
21:28:03
Bike
my understanding though is that this stuff should be less of a problem for _synchronous_ signals like sigfpe, which is after all signaled at only particular places (where we do a floating point operation)
21:41:18
drmeister
Does the unwinding happen with a library that we can get debug information for on linux?
22:02:20
Bike
i could try. at the moment it's just crashing outright instead of just signaling weird errors like it used to, though
22:14:32
Bike
and then if you try to abort you get the same out-of-extent-unwind so you're stuck in the debugger forever.
23:12:39
drmeister
Do we need to be able to get the declarations for a function from the function-description?
23:29:54
drmeister
I have made FunctionDescription_sp objects literals - but I don't set the entry point in the literal.
23:30:12
drmeister
I create the FunctionDescription_sp object at load time and then I set the entry point using a function pointer.
23:31:04
drmeister
Once I get it working I'll look closely at it and see if I can set the entry point in the FunctionDescription_sp object directly.
23:40:54
drmeister
The solution is going to involve the ltv/function-description - I need to write out a reference to the entry-point.
0:18:25
drmeister
FunctionDescriptions used to be raw blocks of data with a name appended with "^DESC". That's gone now and they are first class objects.