|
From: Niall D. <ndo...@bl...> - 2013-04-18 14:40:25
Attachments:
smime.p7s
|
> 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. Perhaps I miscommunicated. QNX runs on x86 just as it does on ARM. It's micro-kernel, so it can distribute. QNX prefers if the nodes it distributes itself over are the same endian, but other than that it doesn't really care. In other words, just to be absolutely clear, you can have an x86 QNX process running on a PC yet using an ARM QNX kernel running on an attached ARM device. That x86 QNX process will see a world identical in every way to as if it were running on the ARM device: same filesystem, context switches, everything. So what I'm saying is: discount any worries about paths and libraries not matching up. What remains in valgrind itself to get an x86 compiled binary to valgrind an ARM executable? > You are describing a binary translation system - not too bad when the > host and target OS's are similar in semantics. In this situation they're identical. Different architectures, but the code won't notice. > DEC's binary translation systems come to mind. Intercept the system > call instructions themselves, and revector to jackets. In micro-kernel there is no such thing as a syscall. Just messaging, which is transport agnostic. In our valgrind port to QNX we emulate a syscall interface for the benefit of valgrind only. Niall |
|
From: Niall D. <ndo...@bl...> - 2013-04-18 15:31:31
Attachments:
smime.p7s
|
> > So what I'm saying is: discount any worries about paths and libraries > > not matching up. What remains in valgrind itself to get an x86 > > compiled binary to valgrind an ARM executable? > > Early parts of coregrind run some tests on the host (x86 in this case) to figure > out what kind of environment coregrind is operating in. Useful to know. > The handling of signals (sigaction(), signal handlers, etc.) is delicate: > various things must match between host and target. Everything matches. It's all QNX. > > So what I'm saying is: discount any worries about paths and libraries > > not matching up. What remains in valgrind itself to get an x86 > > compiled binary to valgrind an ARM executable? > > Ah I misunderstood and thought you were talking about sending system calls > from linux/x86 to QNX/arm. > > The problem with what you propose is that you've just moved your problem > from needing to support system call translation (hard) to needing to support the > QNX platform (also hard). Sorry if I confused you. There is a fully functional almost complete port of valgrind to QNX/x86 and QNX/arm, so supporting the QNX platform isn't an issue. And everything (PC and device) is running QNX, so no problem there either. So apart from some early architecture-specific parts of coregrind, theoretically it ought to be straightforward to run an ARM-targeted valgrind compiled as x86 then? Niall |
|
From: John R. <jr...@bi...> - 2013-04-18 16:00:55
|
> So apart from some early architecture-specific parts of coregrind, > theoretically it ought to be straightforward to run an ARM-targeted valgrind > compiled as x86 then? Theoretically, a complete instruction-by-instruction emulator for a user mode process on Linux or QNX is a "straightforward" programming exercise. In practice, that exercise takes a while. The documentation is missing/incomplete/incorrect, for both the software and the hardware. In many cases an experiment or two [or more] is necessary to determine enough truth to proceed. Yes, it takes only 3 months to do "90%" of the job. Then it takes 6 more months to do the remaining _90%_, and a year after that until customers are happy. -- |
|
From: Julian S. <js...@ac...> - 2013-04-30 16:58:23
|
> So apart from some early architecture-specific parts of coregrind, > theoretically it ought to be straightforward to run an ARM-targeted valgrind > compiled as x86 then? Mmmhmhm .. I wouldn't like to say that. I imagine there would be a lot of places where small details would bite you. One that comes to mind is the debuginfo reader .. will it correctly handle ELF/Dwarf for ARM when running on an x86 host? If it's not too stupid a question, what's the motivation for doing this cross-platform operation? J |
|
From: Niall D. <ndo...@bl...> - 2013-04-19 15:20:21
Attachments:
smime.p7s
|
> > So apart from some early architecture-specific parts of coregrind, > > theoretically it ought to be straightforward to run an ARM-targeted > > valgrind compiled as x86 then? > > Theoretically, a complete instruction-by-instruction emulator for a user mode > process on Linux or QNX is a "straightforward" programming exercise. In > practice, that exercise takes a while. The documentation is > missing/incomplete/incorrect, for both the software and the hardware. In many > cases an experiment or two [or more] is necessary to determine enough truth to > proceed. > > Yes, it takes only 3 months to do "90%" of the job. Then it takes 6 more months > to do the remaining _90%_, and a year after that until customers are happy. Sure. By straightforward I meant that one knows that if one keeps at the problem, you'll eventually get there because the problem is trivial even if lengthy i.e. implementation tends towards bounded time and resources. By non-straightforward I would mean that no one knows the answer, or even if there is an answer at all. Implementation there tends to be a cash hole. Thanks for the advice. It's much appreciated. Niall |
|
From: John R. <jr...@bi...> - 2013-04-18 15:06:24
|
> So what I'm saying is: discount any worries about paths and libraries not > matching up. What remains in valgrind itself to get an x86 compiled binary > to valgrind an ARM executable? Early parts of coregrind run some tests on the host (x86 in this case) to figure out what kind of environment coregrind is operating in. The handling of signals (sigaction(), signal handlers, etc.) is delicate: various things must match between host and target. -- |
|
From: Tom H. <to...@co...> - 2013-04-18 15:08:44
|
On 18/04/13 15:40, Niall Douglas wrote: > Perhaps I miscommunicated. QNX runs on x86 just as it does on ARM. It's > micro-kernel, so it can distribute. QNX prefers if the nodes it distributes > itself over are the same endian, but other than that it doesn't really care. > In other words, just to be absolutely clear, you can have an x86 QNX process > running on a PC yet using an ARM QNX kernel running on an attached ARM > device. That x86 QNX process will see a world identical in every way to as > if it were running on the ARM device: same filesystem, context switches, > everything. > > So what I'm saying is: discount any worries about paths and libraries not > matching up. What remains in valgrind itself to get an x86 compiled binary > to valgrind an ARM executable? Ah I misunderstood and thought you were talking about sending system calls from linux/x86 to QNX/arm. The problem with what you propose is that you've just moved your problem from needing to support system call translation (hard) to needing to support the QNX platform (also hard). Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: John R. <jr...@bi...> - 2013-04-18 15:08:46
|
> So what I'm saying is: discount any worries about paths and libraries not > matching up. What remains in valgrind itself to get an x86 compiled binary > to valgrind an ARM executable? Look at vgdb, which performs another kind of virtualization. In some ways that much is required for cross-platform valgrinding. -- |