|
From: James C. <cl...@cc...> - 2008-08-19 15:16:26
|
Hi, I know there's no official port for Solaris / SPARC but does anyone know if there's at least a partial implementation somewhere? There's been a little bit of talk about it on various mailing lists but nothing concrete. If there's nothing available what would be the best way to start. I read that the suggested way to was to go from linux/x86 -> solaris/x86 ->solaris/SPARC is this still true. And one final thing -- what would be a decent estimate for how much work / how long the port would take assuming decent knowledge of valgrind and the target platform? Thanks, Jim |
James Clause wrote: > I know there's no official port for Solaris / SPARC but does anyone > know if there's at least a partial implementation somewhere? There's > been a little bit of talk about it on various mailing lists but > nothing concrete. > > If there's nothing available what would be the best way to start. I > read that the suggested way to was to go from linux/x86 -> solaris/x86 > ->solaris/SPARC is this still true. And one final thing -- what would > be a decent estimate for how much work / how long the port would take > assuming decent knowledge of valgrind and the target platform? Be aware of the direct commercial competition on Solaris SPARC, such as Purify and Quantify from IBM [Rational], and Insure++ from Parasoft. They do not cover every aspect of the valgrind milieu, but in many environments they do the job very well. There are two major areas of work: the operating system, and the hardware. They are mostly separable, although they do overlap regarding the arguments and results for system calls. The path linux+x86 ==> solaris+x86 ==> solaris+SPARC is nice because it gives an implementation for solaris+x86. Using linux+SPARC as a middle would be useful, too, but perhaps the audience is smaller. Studying linux+PowerPC could be helpful because both SPARC and PowerPC have fixed-length instructions. Find a partner (or two, but not more.) If you work together, and only on this project, then it should take a couple of months to get memcheck running on one small non-threaded C program. A complete implementation, covering threads and non-native execution, and all tools and all testcases and all opcodes and all system calls, and with only a short list of bugs, might take three or four times as long. -- |
|
From: James C. <cl...@cc...> - 2008-08-19 22:25:59
|
John, Thanks for the response. The final goal of the port isn't to use the current set of valgrind tools but to have a full featured dynamic binary instrumenter for Solaris / SPARC. I'm not aware of anything that meets that criteria. Maybe someone else knows something that does. The closest thing that I'm aware of is the dbx debugger's runtime checking. However, it doesn't look like it's designed to support custom tools. ~Jim On Aug 19, 2008, at 3:30 PM, John Reiser wrote: > James Clause wrote: >> I know there's no official port for Solaris / SPARC but does anyone >> know if there's at least a partial implementation somewhere? There's >> been a little bit of talk about it on various mailing lists but >> nothing concrete. >> >> If there's nothing available what would be the best way to start. I >> read that the suggested way to was to go from linux/x86 -> solaris/ >> x86 >> ->solaris/SPARC is this still true. And one final thing -- what >> would >> be a decent estimate for how much work / how long the port would take >> assuming decent knowledge of valgrind and the target platform? > > Be aware of the direct commercial competition on Solaris SPARC, > such as Purify and Quantify from IBM [Rational], and Insure++ from > Parasoft. > They do not cover every aspect of the valgrind milieu, but in many > environments they do the job very well. > > There are two major areas of work: the operating system, and the > hardware. > They are mostly separable, although they do overlap regarding the > arguments > and results for system calls. The path linux+x86 ==> solaris+x86 ==> > solaris+SPARC is nice because it gives an implementation for solaris > +x86. > Using linux+SPARC as a middle would be useful, too, but perhaps the > audience is smaller. Studying linux+PowerPC could be helpful because > both SPARC and PowerPC have fixed-length instructions. > > Find a partner (or two, but not more.) If you work together, and > only on this > project, then it should take a couple of months to get memcheck > running on > one small non-threaded C program. A complete implementation, > covering threads > and non-native execution, and all tools and all testcases and all > opcodes and > all system calls, and with only a short list of bugs, might take > three or four > times as long. > > -- |
|
From: Vince W. <vi...@cs...> - 2008-08-20 15:58:00
|
On Tue, 19 Aug 2008, James Clause wrote: > Thanks for the response. The final goal of the port isn't to use the > current set of valgrind tools but to have a full featured dynamic > binary instrumenter for Solaris / SPARC. I'm not aware of anything > that meets that criteria. Maybe someone else knows something that > does. The closest thing that I'm aware of is the dbx debugger's > runtime checking. However, it doesn't look like it's designed to > support custom tools. It's not full featured, but you can do DBI of a sort using Qemu if you aren't afraid of digging around in the internals. I only bring this up because co-incidentally I've been working on using Qemu to get instruction/basic-block counts on linux/SPARC binaries. Currently about 1/3 of the SPEC2000 binaries will run properly, I'm working on getting the rest to run. I don't think there is support for Solaris binaries though. Adding SPARC support to valgrind will be difficult I imagine, if only because of register windows and branch-delay slots. Vince |