|
From: Greg P. <gp...@us...> - 2005-08-24 06:12:10
|
Some notes about porting Valgrind 3.x to Mac OS X / PowerPC:
* Overall, Valgrind 3.x looks far more portable than 2.x.
I appreciate all of the hard rewriting work; it should
begin to pay off soon. Thanks!
* Darwin always uses a 64-bit off_t, even on 32-bit architectures.
(FreeBSD may also do this.) Valgrind currently allows off_t to
be pointer sized only, but it doesn't look like there is any
strong dependence on this anywhere.
* dispatch.S should be platform-specific instead of arch-specific.
In particular, Darwin's assembler is not GNU as, so the file's
syntax would be wrong even if everything else were the same.
It should be reasonable to change dispatch-$VG_ARCH.S to
dispatch-$VG_OS-$VG_ARCH.S .
* Some Darwin syscalls take 7 arguments (in particular, mmap()
with 64-bit off_t offset). Valgrind currently provides
arg1..arg6. I don't see any obvious 8-argument syscalls.
Do other architectures define a 7th syscall argument and
just never use it, or do they have a 6 argument max?
* Darwin syscalls return a full 64-bit result, even on 32-bit
architectures. In particular, the lseek() syscall returns
a 64-bit off_t in registers r3 and r4. For syscalls that
return a 32-bit int, the kernel sets the other return
register to zero (or the appropriate sign extension for
signed return types). I don't know how much of an effect
changing this would have.
* Darwin/PPC syscalls indicate success and failure in an unusual
way: successful calls and failed calls return to different
points. A syscall call usually looks like this:
// ...set up parameters here...
sc // make the syscall
b BAD // failed calls return here
GOOD:
nop // successful calls return here
// ...handle success case here...
blr
BAD:
// ...handle failure case here...
blr
Handling this in VG_(do_syscall_for_client) isn't too bad.
One option is to store the PC of the last simulated `sc`
in the thread state, updating it before each call. Another
is to store a "sc failed" bit in each thread state, updating
it after each call. In either case, the simulated PC after
completion of the simulated `sc` would be adjusted based on
the result of the real `sc` or the syscall wrapper. The
syscall restarter would use the extra thread state to decide
whether to back up on instruction or two.
Handling this in VEX might be more difficult, because VEX
might need to know that `sc` looks like a conditional branch
in basic block analysis.
(Of course, Mach traps use `sc` but don't use the PC-modifying
calling convention. However, Mach traps are an entirely different
ball of wax, and much will be said about them later.)
--
Greg Parker gp...@us...
|