Date: Tue, 5 Nov 2002 12:08:33 -0500 From: Jake Burkholder <jake@locore.ca> To: Max Khon <fjoe@iclub.nsu.ru> Cc: current@FreeBSD.ORG Subject: Re: libc size Message-ID: <20021105120833.V22677@locore.ca> In-Reply-To: <20021105132142.A52607@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Tue, Nov 05, 2002 at 01:21:42PM %2B0600 References: <3DC17C7F.9020308@acm.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Tue, Nov 05, 2002 at 01:21:42PM +0600, Max Khon said words to the effect of; > hi, there! > > On Tue, Nov 05, 2002 at 02:18:23AM -0500, Jake Burkholder wrote: > > > > > Before someone says you can dlopen() from static binaries in order to > > > > implement nsswitch, please provide the patch proving it. Our best > > > > FreeBSD minds don't think it can be done properly and sanely. > > > > > > I have the patch. Currently it is made against RELENG_4 and I have a couple > > > of questions about alpha (however it works on alpha too with a few hacks). > > > Unfortunately, jdp does not have enough time to review it and I have > > > lack of time to port it to -current (that would not be that hard but > > > since sparc64 is now Tier-1 platform the patch should be ported to > > > sparc64 too but I do not have sparc64 hardware and access to > > > panther is very slow from my home). > > > > > > What is the right place to post the patch and test program > > > demonstrating dlopen for statically linked programs? > > > > Put it up somehere on the web or email it to the list. I'd > > be interested in looking at it. > > 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. > > Problems with current patches are: > - I do not know what to do on alpha with _GOT_END_ and > _GLOBAL_OFFSET_TABLE_ symbols. I had to use ld.so.script > to solve missing _GOT_END_ problem and ifdef out _GLOBAL_OFFSET_TABLE_ > usage from alpha/reloc.c for second problem. An advice from alpha rtld > guru will be very useful > - gdb support for shared objects dlopened from statically linked > program is broken > - rtld_exit() is not called on exit so fini functions are not > called on exit > - probably more stuff could be #ifdef'ed out from rtld when it is compiled > with -DLIBDL > - 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) > > Any comments, suggestions, patches will be very appreciated. I think there are more problems than you realize. They are very hard to fix. You've basically hacked rtld to bits. All the ifdefs make it hard to read and maintain. This statically links rtld into any static binary that wants to use dlopen. What was that about saving space on the root partition? -rwxr-xr-x 1 jake wheel 143177 Nov 5 11:57 hello This is more than twice as big as a normal static binary which just calls printf on my system. ~90K bloat just for dlopen. I don't see that you've dealt with getting the linker to generate the tables that rtld needs; an _DYNAMIC section, a dynsym table, a dynstr table etc. These are needed in order to look up symbols in the statically linked binary itself. Getting the linker to do this is not overly difficult, we do it for the kernel, but it bloats the static binaries more. It also creates a special case in the makefiles, unless we do this for all static binaries, which would cause a lot of bloat. As a result of the above, how do you deal with multiple implementations of library services being present? For example a statically linked binary calls malloc, so it has a copy of malloc linked into it. It tries to dlopen a library which also calls malloc. Which copy of malloc does the library use? How does it locate the malloc that's linked into the static binary without the dynamic tables? What happens when the application tries to free a pointer allocated by the library, or vice versa? When David said we didn't think it could be done properly or sanely, we meant it. It must work exactly like it would in a dynamic binary. Jake 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?20021105120833.V22677>