- User Since
- Oct 10 2014, 4:27 PM (366 w, 5 d)
Apr 21 2016
Apr 20 2016
I'm not sure how else we could identify the runtime version. I'm hoping to eventually add a producer string that has the version, but this would just be a git commit for development compilers.
Apr 19 2016
Jan 15 2016
Nov 4 2015
Nov 3 2015
Nov 2 2015
Oct 29 2015
Is this ready to submit?
Is this ready to submit?
Oct 21 2015
More formatting fixes.
Also updated .clang-format to fix the settings for constructor initializers.
Oct 20 2015
Thanks for taking a look!
I moved the expression jit'ing code into LLVMUserExpression.
Oops, I ran clang-format with the wrong arguments. Ran it again.
Oct 19 2015
Oct 13 2015
Oct 6 2015
Submitted in revisions 249456 and 249459.
Oct 1 2015
Merged with head.
Sep 29 2015
Sep 24 2015
Sep 23 2015
I suppose JIT might make more sense if we want to implement more complicated expressions like looping and calling in to go code.
There's lots of issues to solve before we can call into go code however. In addition to the stack I'm not sure what to do about the GC. Also I believe at least some parts of the go runtime are assuming knowledge of the complete call graph and may have issues if we're calling functions from an unexpected place.
So want to just start with something simple.
Hmm. I assumed you're using clang to generate llvm IR, is that not the case?
I don't really want to write a whole go compiler.
Right now I'm interpreting the AST using the ValueObject API. This also lets me reuse the error checking and things implemented in the type system. Reimplementing this in IR seems like it would be more complicated and harder to understand/maintain.
Another concern I have is that the go stack is not compatible with c. If we're going to execute jited code we'd probably also need to allocate a separate stack.
Moved the new files into Plugins/ExpressionParser/Go.
Sep 22 2015
Sep 16 2015
I am confused as to why we need to do this. If you have a memory thread, it
might be backed by a real thread, or it might not. If it is backed by a
real thread, we should be asking the real thread why it really stopped and
the memory thread will say that it stopped for the same reason the real
thread stopped. If it isn't backed by a real thread, then the memory thread
will say why it stopped. Can you elaborate on why you think you need to do
Sep 15 2015
Fix cmake build.
Ok, I've changed it to use the symbol table like the ASAN runtime does.
I'm not seeing any language info in the elf or macho file headers.
It looks like there's also a gosymtab section I could look for, but the name is different in macho and elf so I'd prefer this one.
I've updated this to load the plugin when modules are loaded, added a setting to enable/disable the goroutine plugin, and added a test.
Sep 14 2015
Sep 4 2015
Please take another look.
Sep 2 2015
Jul 15 2015
Sync to head
Jun 9 2015
Oops, I guess building the "run testsuite" scheme in xcode doesn't actually run the tests.
This version fixes the tests on my linux machine.
Jun 8 2015
Another try at updating.
Sync to head
May 18 2015
I don't have commit access, can you submit this?
May 13 2015
Update to top of tree
Apr 15 2015
Please take another look. I've moved around some methods between ClangASTType, ClangASTContext, and TypeSystem based on trying to implement a TypeSystem for go.
Apr 6 2015
Apr 2 2015
I think I've addressed most of your comments, except removing more methods from TypeSystem.h. I've added TODOs for the methods I think should be removed, and the ones I'm unsure about.
I've also changed the style for the ClangASTContext specific methods.
Instead of ast->Foo(type.GetOpaqueQualType()), it's now ClangASTContext::Foo(type). I think this is cleaner and safer.
If you like this style and agree on which methods to keep I'll go ahead and move the methods.
Mar 30 2015
Oct 30 2014
Oct 20 2014
Oct 15 2014
Not sure if this worked since I wasn't subscribed to the mailing list.