I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there:
http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html
If it's worthy, hopefully it'll end up in the LLVM docs.
I've been writing up my experience embedding LLVM in a Cocoa app. If
anyone would like to see it and give feedback, I'd appreciate it. It's
still not finished, but the first part is there:http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html
If it's worthy, hopefully it'll end up in the LLVM docs.
That's a very nice start! Do you plan on sandboxing the execution? It
seems like just blindly executing the compiled code could easily crash the
application if you have bad IR. I know that's a bit more advanced, but it
would be nice to have some documentation on ways to sandbox the execution
for this kind of scenario.
Thanks! I worried about what might happen in the case of bad or rogue code. Are you referring to OS X's sandboxing capabilities, or something LLVM supports? I agree blindly executing code is possibly a bad idea, although the intent is that someone creates a DSL, and so the DSL's code generator would constrain what could really be done. That is, the DSL would not allow the user to arbitrarily execute hosting code, but rather the DSL's runtime could call hosting code. Does that make sense?
> That's a very nice start! Do you plan on sandboxing the execution? It
seems like just blindly executing the compiled code could easily crash the
application if you have bad IR. I know that's a bit more advanced, but it
would be nice to have some documentation on ways to sandbox the execution
for this kind of scenario.Thanks! I worried about what might happen in the case of bad or rogue
code. Are you referring to OS X's sandboxing capabilities, or something
LLVM supports? I agree blindly executing code is possibly a bad idea,
although the intent is that someone creates a DSL, and so the DSL's code
generator would constrain what could really be done. That is, the DSL would
not allow the user to arbitrarily execute hosting code, but rather the
DSL's runtime could call hosting code. Does that make sense?
You can get as advanced as you want. I was mainly referring to something
simple like running the generated code in a separate process so a seg fault
won't bring down the entire application.
Ah, I see what you're getting at. I'll mention something about that, but probably won't actually do it for the How-To. It adds a whole level of indirection and complexity to call back into the host app. But it's a good consideration.
I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there:
http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html
This is great. People across the net have been begging for tutorials
of this nature.
If it's worthy, hopefully it'll end up in the LLVM docs.
The major issue I see is that this tutorial is for a hardcoded version
(3.2) of LLVM. It would have to be reworked to always be on ToT and be
integrated into the build so that it gets updated as APIs change (for
example, the #import "llvm/Module.h" is already broken). The highly
platform (even IDE) specific nature of the tutorial makes this
difficult, but I think it might be workable if we had our Mac
buildbots include the relevant software to build this, and disable
building it on other platforms (that might be annoying for developers
on other platforms though).
Regardless, this definitely needs a permanent home! I think this
tutorial is a great start and would help a lot of people.
Pragmatically, it might be best to make this an externally-hosted
tutorial that we could link to (we already do this for at least two
other tutorials). You may want to put this tutorial standalone on
github with Sphinx and publish it with github-pages. It might be
convenient to copy the setup that
<https://github.com/Jonathan2251/lbd> has, which makes it easy to host
the generated pages on github-pages (see
<http://jonathan2251.github.com/lbd/> for the generated version).
However, I think that the part of the tutorial that deals just with
how to coerce Xcode into properly building a project that interfaces
with LLVM would be very good to extract and put into a document; I
think that would help a lot of people get started. I remember that
this last summer I spent a pretty long amount of time fiddling with
all of Xcode's knobs in order to get it to work (I'm mostly a
commandline guy).
-- Sean Silva
I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there:
http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html
This is great. People across the net have been begging for tutorials
of this nature.
Thanks! As was I…
If it's worthy, hopefully it'll end up in the LLVM docs.
The major issue I see is that this tutorial is for a hardcoded version
(3.2) of LLVM. It would have to be reworked to always be on ToT and be
integrated into the build so that it gets updated as APIs change (for
example, the #import "llvm/Module.h" is already broken).
I didn't realize the API was still so much in flux. I guess the only way to deal with that is for automated builds to break and let us know.
The highly
platform (even IDE) specific nature of the tutorial makes this
difficult, but I think it might be workable if we had our Mac
buildbots include the relevant software to build this, and disable
building it on other platforms (that might be annoying for developers
on other platforms though).
I needed two things: one was just, what APIs do I call to embed the LLVM? The other was, how do I build with Xcode? In truth, I'd like to see an LLVM.framework (and a Clang.framework) built; it would make Xcode development much easier, and would remove a big part of the hassle having to do with finding the right libraries to link in. (It would be nice if a namespace level below llvm existed separated by library boundary, so that it would be evident by linker error what library was missing, but I digress.)
Regardless, this definitely needs a permanent home! I think this
tutorial is a great start and would help a lot of people.
Pragmatically, it might be best to make this an externally-hosted
tutorial that we could link to (we already do this for at least two
other tutorials). You may want to put this tutorial standalone on
github with Sphinx and publish it with github-pages. It might be
convenient to copy the setup that
<https://github.com/Jonathan2251/lbd> has, which makes it easy to host
the generated pages on github-pages (see
<http://jonathan2251.github.com/lbd/> for the generated version).
I'll check those out. My personal blog is fairly permanent, but better it be served somewhere that has more than one person tending to it.
However, I think that the part of the tutorial that deals just with
how to coerce Xcode into properly building a project that interfaces
with LLVM would be very good to extract and put into a document; I
think that would help a lot of people get started. I remember that
this last summer I spent a pretty long amount of time fiddling with
all of Xcode's knobs in order to get it to work (I'm mostly a
commandline guy).
Undoubtedly the two (or more) aspects of this how-to can be separated, but sometimes an integrated example like this goes a long way toward fostering understanding. The remaining sections I plan to write are not strictly necessary either, and could be argued orthogonal to this example, but they are helpful and useful in the context of building a Cocoa app that uses LLVM.
Once I get it finished, I'm happy to consider splitting out portions into separate articles. I did amend this one a bit with some "tl;dr" stuff at the top to allow a reader to skip over sections. Perhaps a more thorough effort in this regard might be beneficial.
I didn't realize the API was still so much in flux. I guess the only way to deal with that is for automated builds to break and let us know.
FYI, the API is _always_ in flux; there is no sign of abatement.
I'll check those out. My personal blog is fairly permanent, but better it be served somewhere that has more than one person tending to it.
One major advantage of having it on github is for people to check out
the repo (for some reason this is a lot more appealing than just
downloading a tarball), and opening it up and hacking on it
themselves. Then they also might contribute back.