Re-wrote the README file.

Re-wrote the README file.

Now, there are two ways I can actually go about gathering data from the
monitored program: I can set breakpoints on each line that changes a pointer's
address, or I can begin at the malloc() calls and set breakpoints everywhere
pointers change. Picture the following hypothetical function:

int *test_function(int *pointer_argument) {
    int *p = malloc(sizeof(int) * *pointer_argument);
    return p;
}

Besides the obvious lack of error-checking, consider how this looks in
assembly; probably something similar to the following:

test_function:
    enter   8,0
    mov     rdx, [rsp-8]    ; I may have this wrong, but [rsp-8] is the first
                            ; 8-byte argument.
    mov     rax, 4          ; 4 is assumed to be the size of int() --
                            ; sizeof() is calculated at compile-time.
    mul     rdx, 4          ; This instruction may, again, be off . . .
    push    rcx
    push    rdi
    mov     rdi, rax
    call    _malloc
    pop     rdi
    pop     rcx
                            ; The return value of malloc() is already in rax
    leave
    ret

(I'm rather rusty as far as assembly goes, so that example may be completely
off -- but it stands as a demonstration. Besides, this doesn't store the
return value inside something on the stack, then move it off into rax.
Whatever.)

Something similar to the "taint" system of Perl/Ruby could work very well
here. Consider, for the moment, anything that is dynamically-allocated memory
is "tainted", and any pointer within it is also tainted. If you track the
"taint" well enough, you lose no information whatsoever. Indeed, it may even
be faster to do it this way, if I disassemble enough at a time . . . and place
the breakpoints strategically. For example, in the preceeding example, [rsp-8]
may or may not be marked as tainted. We'll assume that it is not, and instead
it is the address of a stack variable. Now, calls to [*]+malloc() are handled
specially -- immedately after a malloc call, rax is marked as "tainted" with
dynamic allocation. Now, if an instruction such as "mov rax, 4" was to come
along sometime, then rax would be marked as "untainted", since its previous
value is gone. On the other hand, if it was something more like
"mov rdi, rax", then rdi would be marked as tainted . . .

I think that's enough pontification. What it means is that I need a
disassembler . . . I'm beginning to wonder if I should actually just use
libbfd . . .