On 6/1/06, tkho(a)ucla.edu <tkho(a)ucla.edu> wrote:
One thought that has recently crossed my mind: Building off his framework and putting much of the code in the server may not have been a great idea, since the only real need for the server is to get the unix pid of the thread.
Nah, I think it was the right thing to do. You definitely want the server to do the dirty work here.
+ /* return base address of allocated memory in eax */ + asm("movl %0, %%eax" + : + :"r"(mem) + :"%eax"); + asm("int3"); /* execution doesn't continue past here */
Better surround that with #if defined(LINUX) && defined(__i386__), or whatever the right symbol is, and explain better why 'int3' is how you return to the caller of ptrace.
+ printf("using allocator in kernel32 at 0x%08x\n", + (unsigned) allocator);
You might want to strip out the debugging prints...
+enum remote_op_code +{ + REMOTE_OP_NEW_THREAD, + REMOTE_OP_VM_ALLOC, + REMOTE_OP_VM_FREE, + REMOTE_OP_VM_PROTECT, + REMOTE_OP_VM_QUERY, + REMOTE_OP_VM_MAP, + REMOTE_OP_VM_UNMAP, + REMOTE_OP_VM_FLUSH +};
I would have ripped out any part of his patch you're not implementing, just to keep the size down...
+ case REMOTE_OP_VM_ALLOC: + { +#if defined(linux) && defined(__i386__) + int pid; + struct user_regs_struct oldregs, regs; + struct remote_op_params_vm_alloc *params; + struct remote_op_result_vm_alloc result; + ...
You probably want to hide all the ptrace stuff inside a separate function called, maybe, posix_remote_mmap(...). Also, which bugzilla bugs / conformance tests will this fix? If the answer is 'none', maybe you need to write them. - Dan