Date: Fri, 7 Jun 1996 14:30:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett Wollman) Cc: terry@lambert.org, questions@freebsd.org Subject: Re: Statically linked vs. Dynamically linked programs (fwd) Message-ID: <199606072130.OAA04125@phaeton.artisoft.com> In-Reply-To: <9606072041.AA09707@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jun 7, 96 04:41:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [about executables linked -shared] > > > o library data in image > > I believe this to be incorrect. This is a correct description of the > way Sun's libraries work, but my understanding was that we avoid > this. Nope. Even the ELF shared libraries in Linux link the shared library data into the image. In order to get around this, you would need to be able to multiplex the data address space based on symbols. You could do this with ELF, if your execution loader and process page mapping cooperated. I believe that library data pages are not directly relocatable because the static code is not compiled to produce table-based references that can be relocated for library variable references (the data space is divided into stack and heap, and premapping the data into the heap would be ineffective without Microsoft style __declspec(dllimport) compiler directives). > > o shared library image mmap'ed into process address > > space on startup by modified crt0.o > > No. /usr/libexec/ld.so loader image mmap'ed into process address > space on startup by crt0.o. Shared library images are mmaped by > ld.so. You're right. I skipped this. The ld.so in a proper ELF system is mapped by the image loader, not by the crt0.o, and I wanted it to be generically applicable (this premap is the reason for the 0x08048000 SVR4 EABI ELF image load address -- to leave room for the kernel to map the ld.so in on the processes behalf). > > o library code is PIC (Position Independent Code) to > > allow mapping anywhere for any process. PIC is > > slower than statically linked code for Intel > > processors (artifact of DOS legacy, not a problem > > for most non-Intel chips) > > Not an artifact of DOS legacy, but rather a result of the paucity of > registers on 8086-family CPUs. I was talking about the cycle overhead of relative vs. absolute jumps; I wasn't aware of any register overhead issues... unless you are referring to jump-table based integration? That's an implementation issue (but as I pointed out in the prvious posting, jump tables are often used as read-only to avoid copy-on-write as a result of the fixups, so you're technically correct: Intel chips need more registers). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606072130.OAA04125>