docs/internals/darwin-notes.txt

[Julian replying to Greg Parker's notes about darwin/ppc32]


> Some notes about porting Valgrind 3.x to Mac OS X / PowerPC:
>
> * 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.

Ok.  This sounds fairly harmless.

> * 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 .

True.

> * 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?

6 args is as many as Linux uses, it seems, and that's why the
m_syswrap abstractions stop at 6.  But clearly that could be
extended to 7 with minimal effort.

> * 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.

I think the m_syswrap abstractions should be able to hide that OK.

> * 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

So you're saying that after sc, execution continues either at
CIA+4 or CIA+8 depending on outcome.  Right?

>   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.

Probably pretty harmless.  There's all sorts of tricks that can
be played.  I think it's a non-problem.

>   (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.)