Re: [Valgrind-developers] SOLARIS / SPARC port

[James C. <cl...@cc...>]

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.
>
> --