-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support compilation, instrumentation, and linking from within seec-trace-view. #26
Comments
The first step of this should be to turn seec-cc (seec-clang-test) into a transparent replacement for gcc/clang that performs instrumentation at the appropriate stage. Hopefully we can leverage the Clang driver to do this. Update: at the moment it seems unlikely that we'll be able to custom Clang's driver for this. A nice solution would have been to insert "-emit-llvm" and "-O0" into the command line arguments, run them through the driver, replaced "clang" with "seec-cc", and finally used a LTO pass to add the SeeC instrumentation. Unfortunately it seems that LTO uses a fixed libLTO at the moment (i.e. /usr/lib/libLTO.dylib on OS X), and we don't want to replace the system's libLTO with SeeC's. If it becomes simple to use custom passes with libLTO, then we should investigate this further. For now, we'll have to create a simpler tool. |
Perhaps we can make a simple command line tool that takes a list of object files, links all the LLVM modules together, instruments them, then passes this new object file along with any previously specified native object files to the standard linker to generate the final executable. This might server as a suitable alternative to the above. |
We now have the tool described above, named seec-ld. The next step is to make seec-cc a little bit smarter. Essentially it should use the Clang Driver to generate a compilation, but make compile actions use seec-cc and linking actions use seec-ld. This isn't going to magically work for all situations, but it should handle the compile process used by students. |
…ore like the clang driver. Essentially it is the clang driver now, with the following differences: * it uses SeeC-specific FrontendActions for code generation. * it never emits native object files (it emits LLVM bitcode instead if -emit-obj is requested). * it replace linker commands with calls to seec-ld. * it adds the command line arguments that are required when compiling programs to be used with seec (-fno-builtin, -D_FORTIFY_SOURCE=0, -D__NO_CTYPE=1, -lseecRuntimeTracer, etc.) We also updated seec-ld to have a better system for passing in arguments that shouldn't be forwarded to the real linker, but are used by seec-ld itself.
08b6504 implements the next major piece of this, but we still need to wire up the serialization of the SeeC-Clang mapping metadata. |
…mation into the llvm::Module by hooking CodeGenAction::ModuleComplete() - which requires seec-clang 3e779edf7a7c6f06085cb19ab5f557d3b5524364. This is the next major piece of #26.
All the major changes to seec-cc are done now. If we want to add compilation to seec-trace-view, it should be trivial to call out to seec-cc with the appropriate arguments. |
Dropping this from 13.08 as using seec-cc should be sufficient for the trial run. |
This issue was moved to seec-team#13 |
For the use trials, seec-trace-view should be a complete interface to using the SeeC system. Users should be able to compile (with instrumentation) their source code directly to an executable file (from the user's perspective) from within seec-trace-view. Don't rely on the clang binary to perform linking for us, as there may be a version mismatch between the installed binary and our Clang libraries.
The text was updated successfully, but these errors were encountered: