mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-04 10:21:20 +00:00
79 lines
3.2 KiB
Plaintext
79 lines
3.2 KiB
Plaintext
[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.)
|