1. The input is a C-like preprocessed source, the output is a NASM-like strip. dg -> define gadget, which must be slid by library slide du -> define local, which must be slid by strip slide dd -> define data (%define dd -> dq for 64bit) 2. we implement lazy assignment. that is, an assignment is not guaranteed to generate code, it only guarantees that when first using the assigned variable, it will have the desired value. however, since we do not have proper flow analysis, any assignment in a loop cannot be lazy. see 'const' 3. immediate expressions involving local pointers cannot be simplified, unless they can be reduced to: PTR + scalar. that is because there is one single final addition applied by the assembler, after full evaluation. 4. strings are treated as implicit addresses. therefore, b = "a" + 1 really means: str = "a" b = &str + 1 also, compound expressions are treated just like strings, with "long" values instead of characters 5. imports are implicit addresses. to actually use external variables, do *optind = 0; a = *optind; 6. sometimes, it is better to use multiple assignments for the same value fd = fd2 = open(...); read(fd, ...); close(fd2); instead of fd = open(...); read(fd, ...); close(fd); 7. this contrived load/store architecture stems from the assumptions that some rop gadgets are hard -- or impossible -- to find. for example, it is hard to load r1 without r0 8. jumping to labels in the past is tricky, because stack above us is destroyed by calls in-between. for the same reason, parameters referencing things in the past are WRONG: label: x = 1; printf("x=%x\n", x); if (modify(&x)) goto label; stack above modify is destroyed, so jumping back to label is problematic. also, any use of *(&x) is probably doomed. therefore, we need to reserve some stack space before any such calls. see '[[stack]]' ==== const: used for var = immediate to avoid generating *&var = immediate var is inlined and defined as immediate, when possible useful inside loops volatile: used for x = var to force generating x = *&var var is never inlined needed when a variable is used before and after a function call therefore "const volatile" is perfectly ok :) because the var will never be inlined, but will not generate code for assignment ==== extern function[[attr]]; a = function; a(); will not respect import attributes [[attr]]a(); will respect call attributes