Search
Wednesday, 23rd of June 2021, 21:29:30 UTC
21:29:38
drmeister
https://www.irccloud.com/pastebin/BR9surPT/
21:29:59
Bike
uh, yeah, like that. guess it worked?
21:30:10
drmeister
Although I appear to be using libunwind from llvm.
21:31:09
drmeister
LD_LIBRARY_PATH was set
21:31:55
drmeister
And the INCLUDES was still set.
21:32:30
drmeister
Now I should be using libunwind from gnu
21:33:05
drmeister
I had removed the --unwind=libunwind --rtwhatever=compiler-rt
21:33:39
drmeister
--unwindlib=libunwind --rtlib=compiler-rt
21:34:24
drmeister
This is the first time that the link_intrinsics.cc throw is invoked - right - I can trap on that.
21:36:53
Bike
oh, i think it's actually the throwReturnFrom function?
21:36:55
drmeister
What was this about? error: undefined reference to '_Ux86_64_getcontext'
21:37:02
drmeister
Maybe throwReturnFrom
21:37:13
Bike
that's from not having libunwind linked in
21:37:38
drmeister
It does have -lunwind and -lunwind-x86_64
21:39:53
drmeister
Somehow it's mixing /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so
21:40:01
drmeister
With /opt/clasp/lib/libunwind.so
21:42:22
drmeister
https://www.irccloud.com/pastebin/evAlD37m/
21:48:17
drmeister
Ok, crashed the libunwind version in a udb session.
21:50:33
drmeister
And I have the non-libunwind version in another udb session and it compiled fine.
21:57:46
drmeister
Alright - what would I break on
22:07:35
drmeister
Obvious difference is if I am in the _cxa_throw and put a break on __cxa_begin_catch
22:07:52
drmeister
In the non-libunwind version it stops in PUSH
22:08:04
drmeister
In the libunwind version it doesn't
22:14:25
drmeister
I've got a difference.
22:14:40
drmeister
The non-libunwind uses _Unwind_RaiseException
22:14:54
drmeister
The libunwind version uses __libunwind_Unwind_RaiseException
22:16:40
drmeister
The libunwind version starts in _Unwind_RaiseException but after the first instruction jumps to __libunwind_Unwind_RaiseException
22:18:41
drmeister
https://usercontent.irccloud-cdn.com/file/iciSXzR8/image.png
22:18:50
drmeister
Left is libunwind and right is non-libunwind.
22:19:09
drmeister
It would be interesting to get a debug version of libunwind and libgcc_s
22:19:20
drmeister
Or just look at their respective source code
22:34:39
drmeister
This is the source code for libunwind and libgcc_s (I think)
22:34:40
drmeister
https://usercontent.irccloud-cdn.com/file/jv3McesF/image.png
22:34:50
drmeister
libunwind on the left and libgcc_s on the right.
2:08:44
drmeister
I'm trying llvm libunwind again. I realized that I had not configured llvm to use the patch properly
2:09:10
drmeister
I was explaining it to Lang on discord and I realized I probably made a mistake.
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:02:23
beach
Good morning everyone!
3:14:15
drmeister
Bike: I have a solution for libunwind on linux.
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:17:55
drmeister
He's talking with the libunwind people to come up with a better solution.
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
3:27:58
drmeister
We only need RBP for our own frames and we don't eliminate RBP.
3:28:12
drmeister
I build cclasp successfully with the patch.
3:37:02
drmeister
I'm going to build this again from scratch and if it works I'll push it.
5:14:44
drmeister
::notify Bike I got clasp to look in the /opt/clasp/lib directory using -rpath
5:14:45
Colleen
drmeister: Got it. I'll let Bike know as soon as possible.
Thursday, 24th of June 2021, 9:29:30 UTC