Wow this is a pleasant surprise. I bumped across this posting by accident while searching for something else. I'm the individual that posted this http://sourceforge.net/mailarchive/message.php?msg_id=10655617
I've been working on a port of valgrind to Solaris for a while. I got pretty far on the port(Solaris 8). It came to a stage where it gave the problem points(invalid memory accesses etc) for the code without line numbers and then crashed after that. For a long time I tried but couldn;t figure out why it crashed. Then out came Solaris 10 with this cool tool called dtrace and also libumem support. So I thought why not work on Solaris 10 directly. Big big mistake. The gcc that came with Sol 10 uses Sun's linker ld by default instead of the GNU ld. I dont know why. I even emailed Steve Christensen (who maintains http://sunfreeware.com) to find out. I didn't get a response though. And I couldnt obtain GNU ld for sol-10. So I was basically stuck at that point since valgrind's stage2 needs to be compiled with a linker map which is generated dynamically during the build process. But this was only in the linking stage the compilation phase was ok. So I thought I should merge in ongoing valgrind changes to my port atleast to keep abreast. It has turned out to be quite a bit of effort plus with the arrival of a new member in my family the work is pretty much stuck at that point. I am thinking of restarting the effort again when I finally get solaris express installed. I suppose people could debug memory problems with dtrace, libumem and mdb but that interface would be too completed for "ordinary" people so it is very useful to have something like valgrind. There are limitations to valgrind but it performs decently well and hey it is free!!!. You would have pay a packet to get similar functionality in commercial tools. >Last I looked at Valgrind, it needed to know the precise semantics for >each system call, something which we don't publish and reserve the >right to alter at basically any time (libc is instead the stable >interface). That is true but how often do these semantics actually change. It is true that Sun doesn;t publish the exact syscall interface but that can easily be hacked from the man pages, doing a 'dis' on libc and writing some sample code to test the syscall(the way I did it). Of course now open solaris gives you immediate access to all that. Once the basic valgrind framework is in place it is pretty easily to change syscall semantics within it. So I dont think that is too big an issue. >It sounds cool, but much of that is already present in the Sun Studio >tools (though unfortunately, some parts, like the memory misuse detection >aren't fully functional on x86, only on SPARC). My initial plan was to port valgrind directly from Linux x86 to Solaris SPARC but one of the valgrind developers advised against it. He said that from Linux-x86 to sol-sparc would be too big a jump. A better way would be to port first from linux-x86 to solaris-x86 to first iron out OS dependent issues. Then porting from solaris-x86 to solaris-sparc would be comparitively easier he said, thats why I started porting first to sol-x86. The final goal would be to get it running on sol-sparc. One of my initial headaches was the difference in the postion of the stack on linux -x86 and sol-x86. linux-x86(and sol-sparc) , 32 bit, have the stack postion at the top of the user's address space whereas on sol-x86 it is positioned at 0x08048000. I hope some Sun engineer can explain to me why this is so. I emailed Jim Mauro reg that and he mentioned that it is like that because of some legacy code(that sun had got when it purchased the x86 code from some other vendor or something to that effect) and that there would be no reason to change it. I'm going to try changing it with the open solaris kernel sometime and see what happens. Naveen http://the-solaris-experience.blogspot.com This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
