freenode/#clasp - IRC Chatlog
Search
14:05:11
drmeister
Bike: I looked at the code where I create modules and then pass them to the cmp:with-module macro (that binds cmp:*the-module*) - it all looks fine. Also - I'm able to build to my heart's content.
14:06:37
drmeister
Ok - it's not reproducible - that's why I'm thinking it might be better to keep dumping the module until you find the instruction where it goes from fine to crap.
14:11:28
drmeister
llvm: stable 7.0.0 (bottled), HEAD [keg-only] . - huh? I thought I had 6. Maybe they call 6.0.1 version 7.0
14:15:51
drmeister
kpoeck_: We ran into a strange issue at the end of the day yesterday where llvm module's on Bike's machine are missing all of their functions. I can build the same commit perfectly fine - it's very odd.
14:38:57
drmeister
But hang on - look at the output of 'brew info llvm' I pasted earlier - it is llvm 6.0
14:39:35
drmeister
It just reports funny. First llvm: stable 7.0.0 (bottled) ... and lower down llvm/6.0.1
14:41:29
Bike
i don't know why the hell it's complaining about boehm now, i have two versions of boehm and both have a gc/gc.h
14:58:20
drmeister
I also have two versions of llvm 6.0.1 and 7.0.0 . I made this change to my wscript.config
15:00:43
drmeister
I'm not sure what version of boehm I'm using though - ./waf build_iboehm -v gives me command lines like...
15:02:36
drmeister
['/usr/local/Cellar/llvm/6.0.1/bin/clang++', 'test.cpp.1.o', '-o/Users/meister/Development/dev-clasp/build/.conf_check_02c69fe915796487b1cd503ffaf257dd/testbuild/testprog', '-lgc']
15:03:54
drmeister
ls -l /usr/local/include/gc.h --> lrwxr-xr-x 1 meister admin 35 Nov 8 09:56 gc.h -> ../Cellar/bdw-gc/8.0.0/include/gc.h
15:06:13
drmeister
ls -ld gc --> lrwxr-xr-x 1 meister admin 33 Nov 8 09:56 gc -> ../Cellar/bdw-gc/8.0.0/include/gc
15:08:06
drmeister
I'd nuke bdw-gc and reinstall it - it all happened automatically for me. I just upgraded bdw-gc a few min ago.
15:09:47
drmeister
That might be a bridge too far - I've never had an llvm upgrade that didn't take a hunk of time out of my life.
15:10:26
Bike
"no type named 'ModuleHandleT' in 'llvm::orc::IRCompileLayer<llvm::orc::RTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>'"
15:12:45
Bike
anyway first reference i found for installing a specific version of something with homebrew was outdated so this is going to be so exciting
15:14:04
drmeister
Can you upgrade llvm@6 or nuke llvm@6 and reinstall it? Somehow I got 6.0.1 from brew.
15:15:06
Bike
i'lll double check that 6.0.0 doesn't work and then give it another shot i fucking guess
15:22:28
drmeister
They made some changes to ORC in 7.0.0 and ModuleHandle's are out and something else is in - it will take some time to figure this out (sigh).
15:24:45
drmeister
As I suspected - it doesn't look like a good time yet to upgrade - the ORC JIT is in a lot of flux and the documentation isn't very clear.
15:27:45
Bike
"Hit a fatal error in llvm: Cannot select: 0x7f9eb325bed8: i64 = bitcase 0x7f9eb325be70 / In function: CLASP-CTOR"
15:32:05
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/compile-file.lsp#L293
15:39:38
drmeister
Now that I think about it - I'm doing something different. I'm cloning the module and then generating an object file and writing that out and then with the copy generating a fasl file and writing that out. I don't know why that would be a problem - but it's a bit more shenanigans than before.
15:40:16
drmeister
I don't need to do that now that I figured out how to get stackmaps without using the _mh_bundle_header symbol.
15:42:40
Bike
maybe you can walk back those shenanigans and I can try that? Or i can start adding dumps within there i guess
15:44:20
drmeister
I'd really like to know what is going on - I thought I was doing everything properly
15:44:44
drmeister
And this kind of "works on my machine but not yours" sends off klaxons in my head.
15:45:42
Bike
well, i mean. if we don't have to do it any more we might as well do the simpler thing.
15:46:17
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/cmpintrinsics.lsp#L500
15:47:43
drmeister
The main-function is RUN-ALL (I think) and we are creating a C++ static constructor that registers RUN-ALL as a startup function.
15:48:32
drmeister
All the RUN-ALL's get registered and then later they all get called in the right order.
15:54:57
drmeister
Am I taking the main-function out of one module and trying to ref it from another?
15:57:21
Bike
this time it printed all of them and then got through to the next print after make-boot-function-whatever
17:49:50
drmeister
Can you print the module that is passed to that function and use that function to get the module that the function belongs to and check if they are the same?
17:54:52
drmeister
I think you can invoke (llvy-sys:get-parent <function>) and you will get the Module that it belongs to.
17:59:17
drmeister
So you can print the module you get from (llvm-sys:get-parent main-function) and you can print the module passed to the function.
18:01:48
drmeister
Huh - it might be the hierarchy isn't set up the way I thought it was. You used llvm-sys:get-parent?
18:08:14
drmeister
Confirm get-parent doesn't work with function. There is the llvm class hierarchy and then there is the clasp class hierarchy and they don't match without work.
18:09:23
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/llvmo/llvmoExpose.cc#L2524
18:09:32
drmeister
I mean I just added here... https://github.com/clasp-developers/clasp/blob/dev/src/llvmo/llvmoExpose.cc#L2524
18:12:59
drmeister
CL_EXTERN_DEFMETHOD(Function_O,(llvm::Module *(llvm::Function::*)())&llvm::Function::getParent);
18:21:53
Bike
it looks like things would have to be completely bonkers for it to not match, but i guess this bug is pretty bonkers
18:42:25
drmeister
Yeah - I guessed correctly. I am trying to pass a pointer to a function in module A to a call in module B.
18:44:23
drmeister
ACTION has advanced to the sixth stage of debugging: https://www.spreadshirt.com/6+stages+of+debugging+programmer+men-s+premium+t-shirt-D13177527
18:49:33
drmeister
Oh shit - the ID is a red herring - it's not tied to the module the way I thought it was.
18:56:25
drmeister
I don't know what the problem is right now. The parent of the main-function is the correct module, the one that is passed in to add-global-ctor-function.
19:40:34
shiho
scymtym: drmeister here on shiho's account: We are trying to handle :CHAIN. It gets a list of nodes - we need to turn it into something like (chain x (chain y (chain z)))
19:55:51
drmeister
Hi - I'm talking through shiho's account - well I was a second ago - I'll paste and show you what we mean.
19:57:04
scymtym
so you get a list of elements from the (+ (or bond-atom branch)) expression and the result should be a list of chain nodes shaped like your example above
19:57:54
shiho
We need to transform it into something like the following - with make-node and relate methods doing the translation (we think)
19:58:16
scymtym
yes, that's from (node* (:chain) (* :element elements)), i.e. a :chain node with multiple :element children
20:02:04
shiho
We can create an intermediate object that would be returned by make-node and then take whatever is passed to relate and build the nested structure in relate - or connect it together.
20:11:42
scymtym
shiho: would this technique work: https://techfak.de/~jmoringe/linearize-test.lisp ?
20:20:47
scymtym
well, there will be multiple MAKE-NODE calls. (make-node :chain) 1 time, (make-node :atom (or whatever the children are)) N times, (relate :element <chain> <child>) N times
20:23:18
scymtym
for a single node with a (* :element …) relation, it's basically (finish-node (reduce (lambda (left right) (relate :element left right)) :initial-value (make-node :chain)))
20:26:29
scymtym
in my sketch, each RELATE call extends the tree of chain nodes by adding a new chain node and storing it in the tail slot of the previous one, the CONS only remembers the first chain node so it can be returned from FINISH-NODE
20:40:25
Bike
i tried dumping the module after the functions are erased and it's really depopulated. no run-all, or really no anything.
21:04:07
Bike
i think it's during optimize-module-for-compile-file, before remove-always-inline-functions
21:17:50
drmeister
I have this in DEBUG_OPTIONS (wscript.config) . "DEBUG_LLVM_OPTIMIZATION_LEVEL_0",
21:23:33
drmeister
Maybe - I don't see the connection - but I did change a lot of code for stackmaps.
21:24:35
Bike
5bcc6cf56 is the busted one. you did a fair amount of rearrangement. might have dredged something from the pits by accident
21:51:02
Bike
in cclasp it complains about the (eql module (llvm-sys:get-parent main-function)) thing, i guess because the cclasp definition of eql doesn't handle pointers