libera/#clasp - IRC Chatlog
Search
20:39:25
drmeister
Here is their DWARF compiler described in the paper: https://github.com/frdwarf/libunwind-eh_elf
20:40:14
Bike
that's interesting and all, but wouldn't we just be making things more complicated for ourselves?
20:40:51
drmeister
I'm not thinking about what to do moving forward yet. I'm just playing with ideas.
20:41:22
Bike
gnu libunwind does the cool thing where they use the preprocessor to construct function names, so it's hard to grep through
20:44:55
drmeister
What about this? https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-backtrace.html
20:53:42
drmeister
The original problem was when we compile with clang and we link the gnu libunwind, JITted code that throws an exception fails.
20:55:36
drmeister
We throw an exception and a bunch of stuff happens where eh_frames are interpreted to generate tables that convert return addresses into the next return address to unwind the stack.
20:59:05
drmeister
I wonder if we had the udb debugger connected to clasp with and without libunwind linked in.
20:59:38
drmeister
We could look at the difference between what happens with libunwind and without libunwind when the exception is thrown from the JITted code.
21:02:07
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/lsp/setf.lsp#L628
21:02:55
Colleen
Clhs: macro defmacro http://www.lispworks.com/documentation/HyperSpec/Body/m_defmac.htm
21:03:20
Bike
and it's a nonlocal return since early multiple-value-bind is macroexpanded into multiple-value-call of a lambda
21:05:09
drmeister
I wonder what is going on. It's essentially a try {.... inner(...) ... } catch (ReturnFrom& returnFrom) { ...} ... void inner(...){ throw ReturnFrom(...); }
21:08:49
Bike
trying to figure out what the personality is doing is probably more trouble than it's worth
21:09:49
drmeister
It's going to be running a virtual machine in here that is interpreting the bytecode in the eh_frame - and that virtual machine is not doing the right thing.
21:21:17
drmeister
We don't load compiled files anymore during aclasp build do we? I thought it was all interpreter all the time.
21:29:03
Bike
maybe just loading the compiler, compiling and loading setf.lsp, and then compiling a form with push in it?
21:34:24
drmeister
This is the first time that the link_intrinsics.cc throw is invoked - right - I can trap on that.
21:50:33
drmeister
And I have the non-libunwind version in another udb session and it compiled fine.
22:07:35
drmeister
Obvious difference is if I am in the _cxa_throw and put a break on __cxa_begin_catch
22:16:40
drmeister
The libunwind version starts in _Unwind_RaiseException but after the first instruction jumps to __libunwind_Unwind_RaiseException
2:08:44
drmeister
I'm trying llvm libunwind again. I realized that I had not configured llvm to use the patch properly
2:16:44
drmeister
He says that patch is what we need in the short term and he's talking to people at Apple about a long term fix.
3:14:49
drmeister
That patch was not correct for us because it only worked with the old memory manager - we are bleeding edge - using JITLink.
3:15:41
drmeister
Lang suggested I apply the same patch to this file: llvm/lib/ExecutionEngine/Orc/TargetProcess/RegisterEHFrames.cpp
3:21:08
drmeister
Think about how to use libunwind to get the frame pointers - then we can get rid of the frame pointer dereferencing code.
3:24:30
Bike
we can get it from RBP easily. if we have to worry about frame pointer omitting i don't think that's exposd by libunwind and we'd have to get into the dwarf