Date: Wed, 6 Nov 2002 00:20:50 +0600 From: Max Khon <fjoe@iclub.nsu.ru> To: Jake Burkholder <jake@locore.ca> Cc: current@FreeBSD.ORG Subject: Re: libc size Message-ID: <20021106002050.A72989@iclub.nsu.ru> In-Reply-To: <20021105120833.V22677@locore.ca>; from jake@locore.ca on Tue, Nov 05, 2002 at 12:08:33PM -0500 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> <20021105120833.V22677@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
hi, there! On Tue, Nov 05, 2002 at 12:08:33PM -0500, Jake Burkholder wrote: > > 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. There number of #ifdef's is not large (for me) to make rtld unmaintainable. If this is inappropriate for you there are two obvious ways to solve it: - refactor rtld-elf and move common parts of libdl (or whatever) and rtld-elf to separate files - unifdef rtld-elf and put libdl sources separately The reasons I implemented this as a patch for rtld-elf are: - I did not want to create two almost identical pieces of code - I wanted to make these patches as obvious as they can be. This is just a proof-of-concept work. > This statically links rtld into any static binary that wants to use > dlopen. What was that about saving space on the root partition? I didn't tell you or anyone else that this work is done towards saving space in /. The question was about nsswitch and (in particular) dlopen in statically linked programs. The only way to save space in / and to be able to use nsswitch is "make everyhting shared" exactly like NetBSD did a few weeks ago. I saw a number of complaints about loosing an ability to repair system if something goes wrong. I guess that people just haven't looked at what NetBSD folks have done. Yes, they have a number of statically linked programs in /rescue. Yes, they have created /lib. > -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. This is the price you pay for dlopen. This is how things are in other systems that are capable of using dlopen in statically linked executables. > 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. I do not have Solaris at hand but Linux is not capable of resolving symbols refs in shared objects to main binary. This is not even possible at all. At a time of static linking ld can not know which symbols will supposedly loaded shared library need. Will it need fopen()? Will it need fts_open()? In Linux libdl implementation you can't also use dlopen(NULL,...) in main program. > It also creates a special case in the makefiles, unless > we do this for all static binaries, which would cause a lot of bloat. Are you talking about STATICOBJS and SHOBJS? This is how libpam is built right now. You have different sets object files in shared and static versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile and corresponding /usr/share/mk bits. > 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? A part of answer is above (about ld not knowing which symbols shared object will want). The real solution is to link shared libraries with all objects they will need (including libc). This is how things are implemented in other systems. As a result library will use malloc from libc that will be loaded as a dependency (and this is demonstrated in the example I posted). > What happens when the application > tries to free a pointer allocated by the library, or vice versa? This is not possible for obvious reasons. On Linux you will get SEGFAULT (for the same obvious reasons). Yes, this is a limitation. > 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. You can't get exact behaviour. But this behaviour is sufficient for PAM and NSS. Maybe there are some other (less important) uses for this stuff. Sorry for being too emotional, but none of your questions make sense. I highly appreciate your work on sparc64 but seems that you were in bad mood when typing an answer. /fjoe 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?20021106002050.A72989>