libera/#clasp - IRC Chatlog
Search
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
13:04:14
Colleen
Bike: drmeister said 7 hours, 49 minutes ago: I got clasp to look in the /opt/clasp/lib directory using -rpath
13:23:51
drmeister
I'll check and see if this libunwind works on macOS and if it does then we can just use that.
13:25:10
drmeister
Anywho - I build llvm libunwind in the deploy script and we link it on linux and I set the path to it using -rpath. This all works on linux.
13:25:32
drmeister
Lang is talking to folks at Apple that develop libunwind to fix the problem that we saw with it.
13:27:18
drmeister
Can you change the backtrace code to use libunwind to get the RBP for frames where it is available? Get rid of the frame pointer dereferencing.
13:28:34
drmeister
We are probably the only compiled dynamic language that supports that. I looked at the Julia code - they don't appear to do the work to get arguments.
13:30:26
drmeister
Also, I was reading the llvm.experimental.patchpoint documentation again. It seems to hint at beach's call site approach.
13:30:30
drmeister
"The llvm.experimental.patchpoint intrinsic also lowers a specified number of arguments according to its calling convention. This allows patched code to make in-place function calls without marshaling."
13:32:16
drmeister
"A special calling convention has been introduced for use with stack maps, anyregcc, which forces the arguments to be loaded into registers but allows those register to be dynamically allocated. These argument registers will have their register locations recorded in the stack map in addition to the remaining live values."
13:34:52
drmeister
So let's get the backtrace and debugging stuff nailed down and document a few more things and do a release.
13:40:07
drmeister
Yes - for now - until the libunwind folks and Lang come up with a better solution. They are working on it.
13:42:45
drmeister
There was a different problem with gnu libunwind and llvm libunwind and JITted code on linux. With llvm libunwind it was that the JITted code is hard wired to expect gnu libunwind.
13:43:32
drmeister
With gnu libunwind there is a bug. gnu libunwind takes over unwinding when you link with it and it's busted.
13:45:23
drmeister
Yeah - it was when we first throw an exception from JITted code - it skips the catch in the JITted code.
13:46:07
drmeister
I can bring it up under udb and I can see the different behavior - but it would take some more work to figure out what the problem is.
13:46:51
drmeister
I'd like to have debug versions of gnu libunwind, libgcc_s and whatever defines __gxx_personality_v0 to debug it.
13:48:17
drmeister
You can see differences in the search phase. The gnu libgcc_s calls __gxx_personality_v0 only 4 or 5 times and then jumps to the catch. gnu libunwind calls __gxx_personality_v0 many, many times and then ends up in the wrong catch.
13:50:45
drmeister
Lang will be on in a few hours - I'll ask about the libunwind fix timing. Or if there is any other way around this.
13:53:19
drmeister
I have the source code for gnu libunwind and __Unwind_RaiseException and I can see the call to __gxx_personality_v0 and the arguments and the return values.
13:54:16
drmeister
I can do the same thing with libgcc_s - which works - but again, staring at disassembled code.