Previous: , Up: Super-Mutants   [Contents][Index]


3.5.2 ASM Super Mutants

3.5.2.1 asm-super-mutant Overview

asm-super-mutant software objects are designed to provide the benefits of super-mutant to assembly programs. Its primary advantage is the ability to evaluate the fitness of large numbers of variants of a given target function, in a single process, in a minimal amount of time. Avoiding the per-process overhead in fitness evaluations results in orders-of-magnitude improvements of efficiency.

The asm-super-mutant has been tested with at&t and Intel syntax and for nasm (Intel) and gas (at&t) assemblers. Like asm-heap, it won’t work for arbitrary macro-heavy assembler code.

The asm-super-mutant derives from an asm-heap and also contains the super-mutant methods.

The asm-super-mutant initially contains a complete program executable (initialized from an asm format file). In addition it contains a specification of a target function within the overall program. The target function (specified either by name or as start and end addresses) is used to mark a range of lines within the overall program (returned by CREATE-TARGET).

Like a super-mutant, the asm-super-mutant maintains a collection of mutants, each one being an instance of the asm-heap software object. Each mutant is a variant of the target function.

3.5.2.2 Fitness Evaluation

To perform fitness evaluation, the asm-supermutant performs the following steps:

3.5.2.3 Tool Dependencies

The asm-super-mutant currently depends upon:

The asm-heap, which is the basis for asm-super-mutant and all its variants, uses Intel-format assembly code (Nasm-compatible). In the near future we are planning to switch to at&t assembler syntax and to replace Nasm with a more efficient assembler.

3.5.2.4 I/O File Format

The file is ascii. In internal tests it s generated using the ibm pin tool to observe the execution of a binary program on a test suite.

An I/O file contains 1 or more test runs, and each test run comprises 2 sections: Input Data and Output Data.

The format of Input Data is identical to Output Data, except that the set of registers that are included may differ.

Each section (Input Data or Output Data) contains a section of register lines, followed by a section of memory lines.

In the register section, the values of all significant registers are specified, one per line. This includes general-purpose registers (gpr) i.e. rax rbx, etc. followed by floating-point registers ymm0-15.

Following the registers are values of relevant memory addresses. These include any memory addresses read or written by the function being tested. If the function depends on a global variable for instance, it will be included.

In the first section (registers) each line contains:

For example, the line,

    %rax    00 00 00 00 00 00 01 00

indicates that register rax should contain the value 256.

For the general-purpose registers rax, rcx, rdx, rbx, rsp, rbp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, and r15, all eight bytes will be explicitly included on the line. For the simd registers ymm0-ymm15, all 32 bytes will be explicit.

Memory would be specified with one 8-byte long per line, in big-endian order, consisting of an address, followed by a mask indicating which bytes are live, followed by the bytes themselves. The mask would be separated from the address and bytes by whitespace, but again any other whitespace on the line should be ignored.

For example, the line,

    00007fbb c1fcf768   v v v v v v v .   2f 04 9c d8 3b 95 7c 00

indicates that the byte at address 0x7fbbc1fcf768 has value 0x00, the byte at 0x7fbbc1fcf769 has value 0x7c, and so forth (big-endian order). Note that bytes 0x7fbbc1fcf769-0x7fbbc1fcf76f are live (indicated with "v") while 0x7fbbc1fcf768 is not (indicated with ".").

3.5.2.5 Components

asm-super-mutant software object consists of:

Note that the struct input-specification is a bit of a misnomer as it is used here for both input specification and output specification (their formats are identical so we use the same struct for both).

super-mutant slots:

3.5.2.6 Current Limitations

3.5.2.7 Installing PAPI on Ubuntu

Fitness evaluation requires the PAPI component and the Linux Perf functionality. Building the fitness evaluation program (on the fly during fitness evaluation) requires a C program to compile and link to PAPI. This also requires a .h file to compile.

To install papi:

sudo apt-get install papi-tools

To install perf:

    sudo apt-get install linux-tools-common linux-tools-generic linux-tools-`uname -r`

Perf requires system permission to run. In linux, the value in /proc/sys/kernel/perf_event_paranoid should be set to 1 (Disallow cpu event access by users without CAP_SYS_ADMIN). This is typically set to 3 (maximum paranoia) by default.

This can be accomplished with the following: sudo sh -c ’echo 1 >/proc/sys/kernel/perf_event_paranoid’ sudo sysctl -w kernel.perf_event_paranoid=1 You may need to use: sudo sh -c ’echo kernel.perf_event_paranoid=1 > /etc/sysctl.d/local.conf’ and then reboot for it to take effect.

It’s also a good idea to turn off randomizing of address base (to get more consistency): sudo sh -c ’echo 0 >/proc/sys/kernel/randomize_va_space’ sudo sysctl -w kernel.randomize_va_space=0 sudo sh -c ’echo kernel.randomize_va_space=0 >> /etc/sysctl.d/local.conf’

To get necessary include (.h) file for compiling C harness with PAPI (needed to perform fitness evaluation):

sudo apt-get install libpapi-dev

Then you should be able to enter

papi_avail

and see a list of available PAPI events. asm-super-mutant requires the use of the PAPI_TOT_INS event (total number of instructions executed). After installation, the PAPI library should be found in one of these locations: /usr/lib/x86_64-linux-gnu/libpapi.so /usr/lib/libpapi.so.5.6.1


Previous: , Up: Super-Mutants   [Contents][Index]