Difference between revisions of "Compel"
| Line 10: | Line 10: | ||
Execution of the parasite code starts with the function | Execution of the parasite code starts with the function | ||
| + | <pre> | ||
int main(void *arg_p, unsigned int arg_s); | int main(void *arg_p, unsigned int arg_s); | ||
| + | </pre> | ||
| − | that should be present in your code. The arg_p and arg_s is the binary argument that will get delivered to parasite code by complel _start() call (see below). Sometimes this binary argument can be treated as CLI arguments argc/argv. | + | that should be present in your code. The <code>arg_p</code> and <code>arg_s</code> is the binary argument that will get delivered to parasite code by complel <code>_start()</code> call (see below). Sometimes this binary argument can be treated as CLI arguments argc/argv. |
=== Compile the sources and pack the binary === | === Compile the sources and pack the binary === | ||
| Line 18: | Line 20: | ||
Take a program on C and compile it with compel flags | Take a program on C and compile it with compel flags | ||
| + | <pre> | ||
$ gcc -c foo.c -o foo.o $(compel cflags) -I | $ gcc -c foo.c -o foo.o $(compel cflags) -I | ||
| + | </pre> | ||
To combine the foo.o out of many sources, they should all be linked with compel flags as well | To combine the foo.o out of many sources, they should all be linked with compel flags as well | ||
| + | <pre> | ||
$ ld foo_1.o foo_2.o -o foo.o $(compel ldflags) | $ ld foo_1.o foo_2.o -o foo.o $(compel ldflags) | ||
| − | + | </pre> | |
| − | |||
Pack the binary. Packing would link the object file with compel plugins (see below) | Pack the binary. Packing would link the object file with compel plugins (see below) | ||
| − | $ compel pack foo.o -o foo.compel.o | + | <pre> |
| + | $ compel pack foo.o -o foo.compel.o [-l plugin] | ||
| + | </pre> | ||
| − | The | + | The <code>-l</code> option specifies plugins to be added to the packed binary. Plugin <code>std</code> is added all the time w/o any options. |
The foo.compel.o is ready for remote execution (foo.o was not). | The foo.compel.o is ready for remote execution (foo.o was not). | ||
| Line 38: | Line 44: | ||
Using CLI like this | Using CLI like this | ||
| − | $ compel run -f foo.compel.o -p $pid | + | <pre> |
| + | $ compel run -f foo.compel.o -p $pid [args] | ||
| + | </pre> | ||
Or, you can link with libcompel.so and use | Or, you can link with libcompel.so and use | ||
| + | <pre> | ||
libcompel_exec() libcompel_exec_start()/libcompel_exec_end() | libcompel_exec() libcompel_exec_start()/libcompel_exec_end() | ||
| + | </pre> | ||
| − | calls | + | calls. |
The library calls require binary argument that will get copied into parasite context and passed to it via arg_p/arg_s pair. When run from CLI the arguments are packed in argc/argv manner. | The library calls require binary argument that will get copied into parasite context and passed to it via arg_p/arg_s pair. When run from CLI the arguments are packed in argc/argv manner. | ||
| Line 54: | Line 64: | ||
If you run the parasite binary from CLI, the tail command line arguments are passed into the parasite main() function. | If you run the parasite binary from CLI, the tail command line arguments are passed into the parasite main() function. | ||
| + | <pre> | ||
$ compel run -f foo.compel.o -p 123 -- arg1 arg2 arg3 | $ compel run -f foo.compel.o -p 123 -- arg1 arg2 arg3 | ||
| + | </pre> | ||
In the main() common argc and argv are accessed using the | In the main() common argc and argv are accessed using the | ||
Revision as of 09:38, 22 September 2016
Compel temporary GIT repo is at http://github.com/xemul/compel. Now compel sits in the main criu repo at https://github.com/xemul/criu/tree/criu-dev/compel.
Compel
An utility to execute code in foreign process address space. The code should be compiled with compel flags and packed, then it can be executed in other task's context. The parasite code executes in an environment w/o glibc, thus you cannot call the usual stdio/stdlib/etc. functions. Compel provides a set of plugins for your convenience. Plugins get linked to parasite binary on the pack stage (see below).
How we want it to look like
Execution of the parasite code starts with the function
int main(void *arg_p, unsigned int arg_s);
that should be present in your code. The arg_p and arg_s is the binary argument that will get delivered to parasite code by complel _start() call (see below). Sometimes this binary argument can be treated as CLI arguments argc/argv.
Compile the sources and pack the binary
Take a program on C and compile it with compel flags
$ gcc -c foo.c -o foo.o $(compel cflags) -I
To combine the foo.o out of many sources, they should all be linked with compel flags as well
$ ld foo_1.o foo_2.o -o foo.o $(compel ldflags)
Pack the binary. Packing would link the object file with compel plugins (see below)
$ compel pack foo.o -o foo.compel.o [-l plugin]
The -l option specifies plugins to be added to the packed binary. Plugin std is added all the time w/o any options.
The foo.compel.o is ready for remote execution (foo.o was not).
Execute the code remotely
Using CLI like this
$ compel run -f foo.compel.o -p $pid [args]
Or, you can link with libcompel.so and use
libcompel_exec() libcompel_exec_start()/libcompel_exec_end()
calls.
The library calls require binary argument that will get copied into parasite context and passed to it via arg_p/arg_s pair. When run from CLI the arguments are packed in argc/argv manner.
How to communicate to parasite code
There are several ways for doing this.
If you run the parasite binary from CLI, the tail command line arguments are passed into the parasite main() function.
$ compel run -f foo.compel.o -p 123 -- arg1 arg2 arg3
In the main() common argc and argv are accessed using the
argc = std_argc(arg_p); argv = std_argv(arg_p, argc);
calls. Then use argc and argv as you would use them in normal C program run from shell.
If you run the parasite using library _start/_end calls, you can pass file descriptors to parasite using fds plugin or setup shmem between these two using shmem plugin. See test/async_fds/ and test/async_shmem/ for code examples.