|
From: Naveen K. <g_n...@ya...> - 2005-08-04 19:08:04
|
>valgrind-current. If we do >this in netbsd, it seems that the auxv structures that >we look for in >fix_auxv() are not there. Only the first two we place >are located. If >stage1 is compiled as dynamic, the rest of the auxv >structures can be >found and fixed up. I had a similar problem(no auxv) in Solaris 8 when stage1 was compiled as static. You just need to make up the remaining auxv entries with known info about the OS and stage2 exe and add it just like AT_UME_PADFD or AT_UME_EXECFD. > My suspicion was that loading a dynamic stage2 when >stage1 is also >dynamic could result in some problems, so I tried a >static stage2, >which successfully loaded. The problem here in stage >2 is that the >break() , used internally by malloc in libc syscalls >fail. I dont >think netbsd falls back to mmap like in glibc, I have >not investigated >this closely. I had the exact same problem on Solaris. I circumvented that by using the mapmalloc library which implements malloc using mmap.Is there such an alternative on netbsd ? Worst case you can try to hack mapmalloc on netbsd from solaris. http://cvs.opensolaris.org/source/xref/usr/src/lib/libmapmalloc/ Naveen ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
|
From: Julian S. <js...@ac...> - 2005-08-07 10:24:33
|
Here's a possible plan which might help NetBSD, Solaris 8 and MacOSX. The idea is to get rid of stage 1 completely, and turn stage 2 into a statically linked executable which is completely standalone -- it does not depend on either libc or on any dynamic linking library (ld.so). stage 2 would also have a non-standard load address, as it does currently. Currently stage2 uses dlopen to load the tool. In this revised plan, tools would be statically linked to the core, so there would be a different stage2 for each tool (valgrind_memcheck, valgrind_cachegrind, etc). The result is (for each tool) a statically linked valgrind binary which can be started directly. So .. I already tried out most of this -- the removal of stage1 and the static linking work at least on x86 linux. Another advantage is that there no longer any need for address space padding games to get stage2 to load at the address we want it to. Overall it appears to remove some complexity and Linux-specificness. Once that's done, the next step is to rewrite the address space manager to be much more flexible about address space layout. We know from the FreeBSD folks that address space layout issues are at present a major problem in porting V to FreeBSD, and the same goes for MacOSX, so this seems like a good thing for lots of reasons. J On Thursday 04 August 2005 20:07, Naveen Kumar wrote: > >valgrind-current. If we do > >this in netbsd, it seems that the auxv structures > > that >we look for in > > >fix_auxv() are not there. Only the first two we place > >are located. If > >stage1 is compiled as dynamic, the rest of the auxv > >structures can be > >found and fixed up. > > I had a similar problem(no auxv) in Solaris 8 when > stage1 was compiled as static. You just need to make > up the remaining auxv entries with known info about > the OS and stage2 exe and add it just like > AT_UME_PADFD or AT_UME_EXECFD. > > > My suspicion was that loading a dynamic stage2 when > >stage1 is also > >dynamic could result in some problems, so I tried a > >static stage2, > >which successfully loaded. The problem here in stage > >2 is that the > >break() , used internally by malloc in libc syscalls > >fail. I dont > >think netbsd falls back to mmap like in glibc, I have > >not investigated > >this closely. > > I had the exact same problem on Solaris. I > circumvented that by using the mapmalloc library which > implements malloc using mmap.Is there such an > alternative on netbsd ? Worst case you can try to hack > mapmalloc on netbsd from solaris. > > http://cvs.opensolaris.org/source/xref/usr/src/lib/libmapmalloc/ > > > Naveen > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Kailash S. <hs...@gm...> - 2005-08-07 15:01:59
|
Hi all, On 8/7/05, Julian Seward <js...@ac...> wrote: >=20 > Here's a possible plan which might help NetBSD, Solaris 8 > and MacOSX. The idea is to get rid of stage 1 completely, and > turn stage 2 into a statically linked executable which is > completely standalone -- it does not depend on either libc or > on any dynamic linking library (ld.so). stage 2 would also have > a non-standard load address, as it does currently. >=20 > Currently stage2 uses dlopen to load the tool. In this > revised plan, tools would be statically linked to the core, > so there would be a different stage2 for each tool > (valgrind_memcheck, valgrind_cachegrind, etc). >=20 > The result is (for each tool) a statically linked valgrind > binary which can be started directly. >=20 I think this is a good plan which would greatly help improve portability. > So .. I already tried out most of this -- the removal of > stage1 and the static linking work at least on x86 linux. >=20 Do you have experimental patches for this? I could try this on NetBSD too,= =20 The valgrind port of netbsd is based on a snapshot of valgrind-current from a few weeks ago. > Another advantage is that there no longer any need for address > space padding games to get stage2 to load at the address we > want it to. Overall it appears to remove some complexity and > Linux-specificness. >=20 > Once that's done, the next step is to rewrite the address space > manager to be much more flexible about address space layout. > We know from the FreeBSD folks that address space layout issues > are at present a major problem in porting V to FreeBSD, and > the same goes for MacOSX, so this seems like a good thing for > lots of reasons. Yes please :) >=20 > J >=20 >=20 > On Thursday 04 August 2005 20:07, Naveen Kumar wrote: > > I had a similar problem(no auxv) in Solaris 8 when > > stage1 was compiled as static. You just need to make > > up the remaining auxv entries with known info about > > the OS and stage2 exe and add it just like > > AT_UME_PADFD or AT_UME_EXECFD. > > I have tried this, and the NetBSD linker is still confused and crashes before stage 2 can be loaded. Anyway we are working to debug this and get a dynamic stage2 loaded for now= . Regards, Kailash |
|
From: Julian S. <js...@ac...> - 2005-08-08 09:24:09
|
On Sunday 07 August 2005 16:01, Kailash Sethuraman wrote: > > The result is (for each tool) a statically linked valgrind > > binary which can be started directly. > > I think this is a good plan which would greatly help improve portability. > > > So .. I already tried out most of this -- the removal of > > stage1 and the static linking work at least on x86 linux. > > Do you have experimental patches for this? I could try this on NetBSD too, > The valgrind port of netbsd is based on a snapshot of valgrind-current > from a few weeks ago. I lost them or at least I have no idea where they are any more :-) But it doesn't matter; the important part was checking out the idea. I have just made a new svn branch to play with this stuff and tracking that might be a good plan: svn co svn://svn.valgrind.org/valgrind/branches/ASPACEM aspacem J |
|
From: Kailash S. <hs...@gm...> - 2005-08-08 11:10:29
|
Hi, On 8/8/05, Julian Seward <js...@ac...> wrote: > I lost them or at least I have no idea where they are any more :-) > But it doesn't matter; the important part was checking out the > idea. I have just made a new svn branch to play with this stuff > and tracking that might be a good plan: >=20 > svn co svn://svn.valgrind.org/valgrind/branches/ASPACEM aspacem >=20 > J >=20 After much debugging, dynamic stage2 can be loaded from a static stage1 on netbsd :) . However, we are unable to open the tool due to malloc issues. I shall be trying to locate a library for netbsd that uses mmap as the backend as Naveen suggested. Or hack mapmalloc into NetBSD. I have also checked out the ASPACEM branch, and we will be tracking it closely, and syncing with it. Thanks and Regards, Kailash |