Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!bcm!dimacs.rutgers.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!en.ecn.purdue.edu!milton From: milton@en.ecn.purdue.edu (Milton D Miller) Newsgroups: comp.arch Subject: Re: Page size and linkers (was: Re: SunMMU history) Summary: Really just about linkers, and the AIX 3.1 to be specific Message-ID: <1991Feb12.222516.14470@en.ecn.purdue.edu> Date: 12 Feb 91 22:25:16 GMT References: <1991Feb4.190949.1190@HQ.Ileaf.COM> <1991Feb12.164056.8865@dirtydog.ima.isc.com> Organization: Purdue University Engineering Computer Network Lines: 77 In an effort to reorder object code to provide smaller working sets, md@HQ.Ileaf.COM (Mark Dionne x5551) said: >>md> One thing that would help out here would be a compiler switch that would >>md> produce multiple .o files for a single .c file (one .o file per function). To which suitti@ima.isc.com (Stephen Uitti) responded in article <1991Feb12.164056.8865@dirtydog.ima.isc.com> with: >If you have the compiler generate multiple .o's for .c's, you >need some way to tell the linker, "look here first" when >resolving symbol addresses. In C, if you reference a function, >typically the linker looks for the symbol within the same .o first. > >If the compiler produces a list of what symbols that were in each >.o were global, static, static but relevant to these other .o's, >then user's might accidentally obtain more useful libraries. > [Talks about writing a subroutine library, and the want to have some functions accessable only internally] > >If you can build a library, and say "these are the library >external symbols", using a list that is perhaps outside of the C >sources, then you can build better libraries. If it is easy to >do, maybe more libraries will be built. [Also talks about eliminating unused functions from a source file] >A smart linker could do the reordering, or even dead function >elimination, but an optional external list would make library >writing easier to do right, and bullet proof libraries could be built. > [Story of C novice who wrote index() from K&R breaking stdio, which used a function with that name but different arguments] >Imagine if the linker were smart enough to know that libc should >be hooked up to the libc version of "index()", and the user's >code should be hooked up to his/her own version of "index()". > >I've heard that some big company, GM or someone, has done >something like this. Whoever it was hasn't released it for >the world. We need people who publish software to do it. > >Stephen. >suitti@ima.isc.com I waited a few hours to post because of the lack of first hand knowledge, but since no one has brought it up, I will. Although not quite all that is necessary, the shared libraries in AIX 3.1 (which runs on the IBM S/6000) do have the notion that only some functions should be "exported" to other modules. The list of symbols to be exported are placed in a file provided at link time. There is also the concept of an import list, which lists the names of functions which are available somewhere else (for example, in the kernel) (I think). The biggest complaint I have seen in the comp.unix.aix (besides the data space used by the linker) is that you can't use your own malloc, because the library already has one linked into it (Actually you could use your own malloc, if you are prepared not to use anything from libc). Although this does not solve all the linking problems, it is a place to start, and it does solve the problem with index in the example given above. I don't know if the import files would allow the single c file to be broken up and still preserve static variable binding or not. Maybe someone that has a S/6000 could try? milton Disclaimer: I have only read about the linker; the only time I used it (when I had access to it) was to compile a simple c program written by someone else. PS: Source licenses are supposed to be available about a year after the machine started shipping...