|
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...
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-24 14:07:47
|
On Wed, 24 Aug 2005, Greg Parker wrote: > 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. > > * dispatch.S should be platform-specific instead of arch-specific. > > * Some Darwin syscalls take 7 arguments > > * Darwin syscalls return a full 64-bit result, even on 32-bit > architectures. > > * Darwin/PPC syscalls indicate success and failure in an unusual > way: This is all good stuff. You must be handling these things in your port if you are running real programs, right? It would be good to see your port code to see how you are handling these. N |
|
From: Julian S. <js...@ac...> - 2005-08-24 16:45:24
|
Greg Great stuff. What is the current state of your port? I have a MacOS 10.4 box to hand and would be interested to try it out. It would be good to have an overview of the state of the port and the directions you are going with it. > * Overall, Valgrind 3.x looks far more portable than 2.x. > I appreciate all of the hard rewriting work; Thanks. Note that there are still a lot of cleanups in progress, and in particular a major overhaul of address space management is in progress. That should help non-Linux OSs a lot. > * Darwin always uses a 64-bit off_t, even on 32-bit architectures. Ok. This sounds fairly harmless. > * dispatch.S should be platform-specific instead of arch-specific. 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. 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 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. J |
|
From: Greg P. <gp...@us...> - 2005-08-25 21:53:28
|
Julian Seward writes: > Great stuff. What is the current state of your port? I have > a MacOS 10.4 box to hand and would be interested to try it out. > > It would be good to have an overview of the state of the port > and the directions you are going with it. I'm just starting work on Valgrind 3.x. It will be some time before it builds, much less runs anything. Some of my work from 2.x should carry over, especially the launch process, but this time I'm trying to avoid too much hack-and-slash porting. I'm not sure how much time I'll spend on the PPC and x86 versions. Part of that depends on whether the Linux/PPC version keeps mostly ahead of what I need. Eventually, I expect ports for both architectures. > > * Overall, Valgrind 3.x looks far more portable than 2.x. > > I appreciate all of the hard rewriting work; > > Thanks. Note that there are still a lot of cleanups in progress, > and in particular a major overhaul of address space management > is in progress. That should help non-Linux OSs a lot. Good to hear. I'll be making slow progress at best for some time, and if I get blocked behind some other cleanup I can always write some more syscall wrappers :-) > > * Darwin/PPC syscalls indicate success and failure in an unusual > > way: successful calls and failed calls return to different > > points. > > So you're saying that after sc, execution continues either at > CIA+4 or CIA+8 depending on outcome. Right? Exactly. > > 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. Sounds good. In 2.x, I simply incremented the simulated CIA if necessary in do_syscall_for_client, and that seemed to work. I didn't know whether VEX's analysis was more sophisticated so that would fail sometimes. -- Greg Parker gp...@us... |
|
From: Nicholas N. <nj...@cs...> - 2005-08-25 22:22:10
|
On Thu, 25 Aug 2005, Greg Parker wrote: > I'm not sure how much time I'll spend on the PPC and x86 versions. > Part of that depends on whether the Linux/PPC version keeps mostly > ahead of what I need. Eventually, I expect ports for both > architectures. I'm confused by this... can you run Darwin on x86 now, even if it's not the full MacOS X? Nick |
|
From: Greg P. <gp...@us...> - 2005-08-26 17:51:05
|
Nicholas Nethercote writes: > On Thu, 25 Aug 2005, Greg Parker wrote: > > I'm not sure how much time I'll spend on the PPC and x86 versions. > > Part of that depends on whether the Linux/PPC version keeps mostly > > ahead of what I need. Eventually, I expect ports for both > > architectures. > > I'm confused by this... can you run Darwin on x86 now, even if it's not > the full MacOS X? Yes, Darwin/x86 is available to everyone today, assuming you have hardware that falls under its driver support. -- Greg Parker gp...@us... |