|
From: Niall D. <ndo...@bl...> - 2013-04-17 19:55:34
Attachments:
smime.p7s
|
Dear Valgrind Developers, I was wondering what would be the issues, if any, of valgrinding a foreign architecture process e.g. building an x86 build of ARM valgrind and then using that to valgrind an ARM executable on an x86 machine? Obviously it could load a local set of foreign architecture shared libraries etc. easily enough. I can see perhaps though that the syscall kernel interface might vary, and that could be a problem. Other than that though, what would stand in the way? Surely as it emulates the instruction set it ought to work right? Thanks, Niall |
|
From: Tom H. <to...@co...> - 2013-04-17 20:18:31
|
On 17/04/13 20:55, Niall Douglas wrote: > I was wondering what would be the issues, if any, of valgrinding a foreign > architecture process e.g. building an x86 build of ARM valgrind and then > using that to valgrind an ARM executable on an x86 machine? Obviously it > could load a local set of foreign architecture shared libraries etc. easily > enough. I can see perhaps though that the syscall kernel interface might > vary, and that could be a problem. > > Other than that though, what would stand in the way? Surely as it emulates > the instruction set it ought to work right? This is not supported at all. Yes, in theory VEX might be able to cross translate the code (though I think there might be problems even there) but the big stumbling block is that there is absolutely no support for translating system calls from one architecture to another. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Niall D. <ndo...@bl...> - 2013-04-17 20:22:45
Attachments:
smime.p7s
|
> > I was wondering what would be the issues, if any, of valgrinding a > > foreign architecture process e.g. building an x86 build of ARM > > valgrind and then using that to valgrind an ARM executable on an x86 > > machine? Obviously it could load a local set of foreign architecture > > shared libraries etc. easily enough. I can see perhaps though that the > > syscall kernel interface might vary, and that could be a problem. > > > > Other than that though, what would stand in the way? Surely as it > > emulates the instruction set it ought to work right? > > This is not supported at all. > > Yes, in theory VEX might be able to cross translate the code (though I think there > might be problems even there) but the big stumbling block is that there is > absolutely no support for translating system calls from one architecture to > another. Thanks for the answer. Let us assume that system calls aren't a problem, as we can work around those here thanks to QNX's micro kernel nature by simply pushing syscalls over an IP link. What would be the next major show stopper, purely from within valgrind itself? Thanks, Niall |
|
From: Tom H. <to...@co...> - 2013-04-17 20:29:42
|
On 17/04/13 21:22, Niall Douglas wrote: > Let us assume that system calls aren't a problem, as we can work around > those here thanks to QNX's micro kernel nature by simply pushing syscalls > over an IP link. What would be the next major show stopper, purely from > within valgrind itself? I really have no idea - as far as I know nobody has ever tried it and we have always know that the system calls were a massive hurdle so haven't really thought any more about it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: John R. <jr...@bi...> - 2013-04-17 21:57:54
|
> Let us assume that system calls aren't a problem, as we can work around > those here thanks to QNX's micro kernel nature by simply pushing syscalls > over an IP link. What would be the next major show stopper, purely from > within valgrind itself? The target (ARM) shared libraries. Logically there are two separate name spaces for "the" filesystem (ARM target vs. x86 host) but physically there is only one (the x86 host). Of course you can try LD_LIBRARY_PATH, etc., but probably that's only the beginning. -- |
|
From: Rick G. <rcg...@ve...> - 2013-04-17 22:30:46
|
On 4/17/2013 5:58 PM, John Reiser wrote: >> Let us assume that system calls aren't a problem, as we can work around >> those here thanks to QNX's micro kernel nature by simply pushing syscalls >> over an IP link. What would be the next major show stopper, purely from >> within valgrind itself? > The target (ARM) shared libraries. Logically there are two separate > name spaces for "the" filesystem (ARM target vs. x86 host) but physically > there is only one (the x86 host). Of course you can try LD_LIBRARY_PATH, > etc., but probably that's only the beginning. > You are describing a binary translation system - not too bad when the host and target OS's are similar in semantics. DEC's binary translation systems come to mind. Intercept the system call instructions themselves, and revector to jackets. It gets more complicated when the host/target OS's are significantly dissimilar - you have to do stuff like WINE.... But a fork() on Solaris is substatively similar to fork() on Linux. Rick (been there, done that) |
|
From: Julian S. <js...@ac...> - 2013-04-30 16:47:39
|
> I was wondering what would be the issues, if any, of valgrinding a foreign > architecture process e.g. building an x86 build of ARM valgrind and then > using that to valgrind an ARM executable on an x86 machine? VEX (the instrumenting JIT) was originally designed with cross-JITting in mind, although that ability never got used. It would probably be possible, with some effort, to make that part of it work. But as others have said, the rest of the stuff (system calls, in particular) is majorly problematic and actually getting something to work would take a lot of effort. Keeping it verified/maintained over the long run would be even more effort. J |