Open sampsyo opened 7 years ago
Hey @rhenwood39—in the above commit, I tried exploring your hypothesis that constructing the argument types for LLVMFunctionType
was going wrong. I tried switching to ref-array to make sure we were constructing the array of pointers correctly, to no avail. :cry:
Wait a second! I actually had just not waited long enough for my tsc --watch
to catch up. It works, for me at least!
Ready> def f(a b) a+b
Program: def f(a b) a+b
Read function definition:
; ModuleID = 'calculator_module'
source_filename = "calculator_module"
define float @f(float %a, float %b) {
entry:
%addtmp = fadd float %a, %b
ret float %addtmp
}
Ready>
:tada:
Awesome!
It looks like it still complains when you actually try to call a function though. I'll take a look at that later.
I suppose that makes sense—in this buildCall
method here: https://github.com/cucapra/node-llvmc/blob/03676342f6f5d1224dbb598dd59712f8ecd62b50/src/wrapped.ts#L100-L102
we'll need to use the same trick to build up a C array of pointers from the JavaScript array of objects. Maybe this stanza: https://github.com/cucapra/node-llvmc/blob/03676342f6f5d1224dbb598dd59712f8ecd62b50/src/wrapped.ts#L240-L246
should be put into a helper function and reused there?
Got it working :)
I think we are going to have to go through llvm.ts eventually and convert the voidpp's, etc. to PointerArrays where appropriate. I think we have an issue open regarding that, so I'll make a follow-up note there.
We're currently hitting a segfault when trying to iterate over the arguments of a newly-constructed function. Here's a piece of the traceback, from LLDB: