|
From: Naveen K. <g_n...@ya...> - 2005-08-09 22:12:26
|
>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 Solaris 10 doesn't allow static executables. The reasons they give are here http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl10?a=view Solaris 8 allows it but I am doing most of my work on Solaris 10 now what with all the new bells and whistles (new syscall stuff etc) and what not. I had been wondering why stage2 wasn't being loaded directly in the first place. What you are suggesting though should still be ok for Solaris. All the libraries etc are loaded at the top of the address space so we still have the whole of the address space below stage2 for our use. Naveen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Naveen K. <g_n...@ya...> - 2005-08-09 22:25:11
|
> > 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
Another thing you can check if is whether the auxv
structures are aligned correctly. In stage1 fix_auxv
if delta % sizeof(*auxv) != 0 you are going to have
problems in the current fixup. You need to do some
extra work for that.
if( delta % sizeof(*auxv) != 0 )
{
fprintf(stderr, "Fix auxv better....\n");
struct ume_auxv* temp_auxv = auxv;
while( temp_auxv->a_type != AT_NULL )
temp_auxv++;
memmove( (char*)auxv - delta % sizeof(*auxv) ,
auxv, (temp_auxv + 1 - auxv) * sizeof(*auxv) );
auxv = (char*)auxv - delta % sizeof(*auxv);
}
auxv -= delta/sizeof(*auxv);
Naveen
__________________________________
Yahoo! Mail for Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
|
|
From: Julian S. <js...@ac...> - 2005-08-09 22:58:15
|
>> Solaris 10 doesn't allow static executables. The > reasons they give are here Euh, that sucks, but it doesn't surprise me. There just doesn't seem to be a portable way of making an executable _and_ all the shared objects it depends on be loaded in an out-of-the way place. J |
|
From: Tom H. <to...@co...> - 2005-08-09 23:08:15
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> >> Solaris 10 doesn't allow static executables. The
> > reasons they give are here
>
> Euh, that sucks, but it doesn't surprise me. There just
> doesn't seem to be a portable way of making an executable
> _and_ all the shared objects it depends on be loaded in
> an out-of-the way place.
Is there much difference between statically and dynamically linked
executables which don't reference any libraries though?
Sure the dynamic loader will run but if we don't use libc (or any
other system libraries) then it won't have anything to do.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-09 23:25:16
|
On Wednesday 10 August 2005 00:07, Tom Hughes wrote: > In message <200...@ac...> > > Julian Seward <js...@ac...> wrote: > > >> Solaris 10 doesn't allow static executables. The > > > > > > reasons they give are here > > > > Euh, that sucks, but it doesn't surprise me. There just > > doesn't seem to be a portable way of making an executable > > _and_ all the shared objects it depends on be loaded in > > an out-of-the way place. > > Is there much difference between statically and dynamically linked > executables which don't reference any libraries though? Well ... one would hope not. But it's a bit like Russian Roulette. If for any reason the dynamic loader decides to map in any .so at all, then we are screwed. It might be OK on Linux, but who knows what the Solaris/NetBSD/MacOSX/whatever loader is going to do. > Sure the dynamic loader will run but if we don't use libc (or any > other system libraries) then it won't have anything to do. I guess so; if we can guarantee that we don't use any system libraries. I was hoping to finish my de-glibc-ification of branches/ASPACEM today, but didn't make it. Anyway, once I do the next thing I want to try is to do the final link with -nostdlib, which sounds like a Good Thing to me. ----------- Another way to answer your question is: "Yes, in theory I agree. But as is well known, theory and practice coincide only in theory". J |
|
From: Oswald B. <os...@kd...> - 2005-08-10 15:08:27
|
On Wed, Aug 10, 2005 at 12:07:51AM +0100, Tom Hughes wrote: > > >> Solaris 10 doesn't allow static executables. The > > > reasons they give are here > > > > Euh, that sucks, but it doesn't surprise me. There just > > doesn't seem to be a portable way of making an executable > > _and_ all the shared objects it depends on be loaded in > > an out-of-the way place. > > Is there much difference between statically and dynamically linked > executables which don't reference any libraries though? > has anybody read the ref'd page actually? ;) the linker will do whatever you want it to. there is just no libc.a and other static system libs - biiiig problem. ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-08-10 15:16:02
|
On Wednesday 10 August 2005 16:08, Oswald Buddenhagen wrote: > On Wed, Aug 10, 2005 at 12:07:51AM +0100, Tom Hughes wrote: > > > >> Solaris 10 doesn't allow static executables. The > > > > > > > > reasons they give are here > > > > > > Euh, that sucks, but it doesn't surprise me. There just > > > doesn't seem to be a portable way of making an executable > > > _and_ all the shared objects it depends on be loaded in > > > an out-of-the way place. > > > > Is there much difference between statically and dynamically linked > > executables which don't reference any libraries though? > > has anybody read the ref'd page actually? ;) > the linker will do whatever you want it to. there is just no libc.a and > other static system libs - biiiig problem. ;) Read the documentation?!? What sort of a concept is that :-? Cool. No libc.a is fine -- we are moving towards valgrind being 100% independent of everything, especially libc. Life is much simpler like that. J |