On 6/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
