You mention generating C (or C++) code on the fly and then compiling it and dlopen
-ing it.
I'm doing the same in MELT (a domain specific language to extend GCC).
I don't see any valid reason to avoid putting the code in some (temporary) file. Writing even a million line of generated C or C++ lines is quite quick (in MELT, less than a few seconds, and most of that time is not the I/O!). Compiling that is much much slower (a few dozens of seconds at least), and the interest of generating C or C++ code is notably to take advantage of the optimizations provided by GCC (or some other compiler). Avoiding generating a file would win you just some milliseconds (you won't even be able to significantly measure the difference).
So just generate your file in some temporary *.c
file (you could use hash or timestamp techniques to generate a unique file name), then have GCC compile it into some *.so
(perhaps by fork
-ing some make
process, like I do in MELT), then remove that temporary file (perhaps using atexit
).
BTW, this technique is practically compatible with human interaction on current PCs. MELT has a read-eval-print-loop which generates a new C++ file of a few hundred lines, compiles and dlopen-s it, on each interaction, and it is quite usable!
Avoiding the generation of the file is painful, and the gain is absolutely negligible. You might generate it in some tmpfs
filesystem on Linux (e.g. in /tmp/
). Most of the time would be spent by GCC compiling that file (especially if you compile with some optimization e.g. gcc -O -fPIC -shared somefile.c -o someplugin.so
). The time to write it on disk (by your program) and to read it (and even parse it, for C) by GCC is negligible. Use the -ftime-report option of GCC to understand where GCC is spending its time, it is not in parsing as soon as your pass -O
to GCC.
Some versions of GCC or of other C compilers might reject stdin as input; some C compilers might want to mmap
the C source file (e.g. by using "rm"
as mode for fopen
on Glibc). In general, compiling something which is not a *.c
file as C is non-standard, etc... So better avoid doing that, since the gain is negligible.
If you don't care at all about optimization and want quick compilation of C (not C++) into very slow machine code, consider using instead tinycc (at least on 32 bits machines, on 64 bits it could be buggy) which has a library able to compile some C code inside a string. tcc
and its libtcc.a
is able to compile very fast (more than 10x times GCC) some C code but the performance of the produced machine code is very bad (very slow, unoptimized code).
Once GCC has compiled your generated C code, you can of course remove
the generated source code file. (and you could even also remove the .so
after having dlopen
-ed it).
BTW, you could use clang++
to compile the generated C++ file. And you might use LLVM (and generate internal LLVM representation, without using any file) instead.
See also this answer.
I'm doing run-time code generation where I need to generate a shared library and load the functions created.
Consider also using JIT-compiling libraries such as libgccjit, LLVM or asmjit. Look also into SBCL (which generates machine code at almost every REPL interaction). Of course, you need to understand the relevant calling conventions and ABI on your system. So read also this, elf(5) and Drepper's paper How To Write Shared Libraries