Date: Tue, 5 Nov 2002 15:42:40 +0600 From: Max Khon <fjoe@iclub.nsu.ru> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jake Burkholder <jake@locore.ca>, current@freebsd.org Subject: Re: libc size Message-ID: <20021105154240.A58122@iclub.nsu.ru> In-Reply-To: <3DC77D7D.AFBE56EE@mindspring.com>; from tlambert2@mindspring.com on Tue, Nov 05, 2002 at 12:12:45AM -0800 References: <20021031140542.W86715-100000@volatile.chemikals.org> <20021031220633.3acd0b53.flynn@energyhq.homeip.net> <3DC1AB26.5020708@acm.org> <20021103155858.3be6eda9.flynn@energyhq.homeip.net> <3DC6CB56.8090809@acm.org> <20021104215734.GA47193@dragon.nuxi.com> <20021105125454.A51180@iclub.nsu.ru> <20021105021823.T22677@locore.ca> <20021105132142.A52607@iclub.nsu.ru> <3DC77D7D.AFBE56EE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
hi, there! On Tue, Nov 05, 2002 at 12:12:45AM -0800, Terry Lambert wrote: > > Ok, I put the patch and test program to > > http://people.freebsd.org/~fjoe/libdl.tar.bz2. > > > > Patches are made against RELENG_4 (and all tests were done on RELENG_4) > > but it will not be that hard to port everything to -CURRENT. > > This is just a proof-of-concept work-in-progress. > > > > The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a > > so statically linked programe will have dlopen/dlsym etc. > > I have some similar patches; the main difference is that mine > are actually a standalone library. It utilizes the ".init" > section to cause the initialization to take place normally, > as per a standard constructor. standalone library will be harder to use. if you will name it libdl then all configure scripts will find it and will link with it (even in dynamically linked case). the only way I see is to include dlopen and friend to static version of libc OR move dlopen and friends to libdl from rtld-elf. > Right now, my patches don't work with C++ because the replace > the ".init" section. I have a modified version that actually > uses the constructor list in the standard ".init" section, > instead. can you show me an example of non-working program in C++? > The main issue is the initialization of crt.crt_bp (normally, > this is done via "_callmain"). > > The problem is that in calling __do_dynamic_link(), the argv > argument is NULL in the constructor case. Basically, this > means that the constructor code has to be modified to pass it > in to each initially constructed object... the constructor > has to change from a void to a void *, which most constructors > ignore, for it to work. > > This is also a requirement, if you want the loaded shared obects > that resolve external symbol references to symbols defined by > the binary (e.g. as if they were dlopen'ed by a dymanically > linked binary). that is hardly needed for nsswitch. btw libdl in Linux also is not able to resolve external symbols refs to symbols defined in main (statically linked) object. > > - gdb support for shared objecject dlopened from statically linked > > program is broken > > This is because of the argv, which is really the startup frame base > address, which contains that information; it's not being initialized > in the case where you're calling it. You really need to modify the > crt0 code, and duplicate the dlopen mappings in a libdlopen, instead > of modifying ld.so. > > > > - rtld_exit() is not called on exit so fini functions are not > > called on exit > > I had the same problem; mine came from stealing the section entry; > the way to deal with this is to map the base frame so you can add > an internal .fini traversal function to the atexit(). This has to > be done in a reversible way, so you can't actually use atexit(3) > itself to do the job. I think I can call atexit(rtld_exit) in rtld_init() > > - probably more stuff could be #ifdef'ed out from rtld when it is compiled > > with -DLIBDL > > I don't think so, actually. The question is how the symbols get > in, in the first place. this is not high-priority task > > - xmalloc and friends names in rtld sources probably should be prepended > > with an underscore to prevent name clashes (if this stuff will be included > > in libc.a) > > You can actually deal with this by forcing the load of libc.so, the > first time the dlopen() itself is called, if it's not loaded already, > so the symbols will be available. It's ugly, but it works, in lieu > of linking all .so's that make libc calls against libc.so (like you'd > reasonably expect). this is not needed. malloc and friends will be linked from libc.a I am talking about xmalloc and firends which are used in rtld-elf internally. /fjkoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021105154240.A58122>