freenode/#clasp - IRC Chatlog
Search
2:13:25
drmeister
Bike: I was trying to get the shadow stuff to work using a declare. This should be enough - right? (defun foo (x y) (declare (debug 3)) ...)
2:15:03
drmeister
I thought I had it working earlier today but in the last hour I wasn't able to get shadow stack calls to be installed. Perhaps I did something wrong.
3:33:17
drmeister
The times I had shadow stack calls inserted into the function was in bclasp when I set the global variable that causes shadow stack calls to be inserted into every compiled function.
5:04:28
drmeister
::notify Bike I rebased your changes into mine and I'm rebuilding everything on this end. The new backtraces and fastgf changes appeared to work before the rebase and will hopefully continue to work.
5:05:25
drmeister
There's a longer delay now when Clasp starts up - about 7 seconds due to building about 250 dispatchers at startup.
5:06:04
drmeister
Also - the first compilation causes about 600 additional dispatchers to be compiled.
5:06:27
drmeister
It's the way that Clasp starts up - it evaluates every compiled top level form from start to finish.
5:07:11
drmeister
The good news is that this massive cascade of dispatcher compilations comes off without a hitch.
5:10:37
drmeister
We have some ideas of how we could generate the dispatchers at runtime and install them at startup - so that's not a deal breaker. Slow startup isn't a problem for scientific computation - but it is annoying for users.
12:09:30
Colleen
Bike: drmeister said 7 hours, 5 minutes ago: I rebased your changes into mine and I'm rebuilding everything on this end. The new backtraces and fastgf changes appeared to work before the rebase and will hopefully continue to work.
12:13:09
drmeister
Clasp built on my system - but I have a tiny patch to LLVM 5.0 installed that allows it to build on OS X.
12:13:55
drmeister
Clasp failed to build on linux (Shinmera's linut system) because his llvm 5.0 doesn't include that patch - and no one elses will either.
12:14:30
drmeister
The patch is just for disassemble, but it fixes a bug in llvm5.0 that at the moment, crashes the build. :-(
12:15:09
drmeister
So I need to put a #if /#endif around that code so that it builds ok with non-patched llvm5.0
12:15:11
frgo
Do we speak of stock LLVM 5.0 as installed by e.g. homebrew or do we talk about external-clasp's LLVM 5.0?
12:16:15
drmeister
I'm guessing both llvm 5.0 that you are describing were shipped with the bug. It's an easy fix on my end - I forgot to add it with all the other stuff I was doing.
12:19:00
drmeister
Check your llvm5.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h file - maybe it already has the patch - or you didn't get the latest version that I pushed about 7 hours ago.
12:19:48
drmeister
Check your hash as well. If you don't have the latest - you can wait until I wrap and #if/#endif around the effected code (a few hours).
12:24:18
drmeister
This patch allows clasp to generate meaningful backtrace information for JITted code at zero runtime cost.
12:25:39
drmeister
Great - the llvm web site says the release date for llvm 5.0.1 is "To be decided".
12:27:13
drmeister
In that case I'll add a conditional flag to wscript.conf that lets you use the patch if it's been applied and get better backtraces. Or disable the code that requires the patch and loose the names of JITted functions from the backtrace.
12:28:21
frgo
Don't bother what I am doing - It was menat as a pure comment. The less work for you the better
12:30:06
drmeister
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h#L103
12:31:42
drmeister
I couldn't figure out the error message the compiler was giving me before I knew about the fix. I thought they had done some weird C++ std::function vs lambda switch.
12:32:06
drmeister
I'm getting pretty good at reading C++ template programming compiler error messages - I lost it on this one.