jlg@ddsw1.UUCP (JL Gomez) (08/08/88)
From article <422@manta.pha.pa.us>, by brant@manta.pha.pa.us (Brant Cheikes): > > Note to CCC script writers: If we can really link using -F, and it's > really better than the default (-z, apparently), then why not fix CCC > to give ld the -F option unless contraindicated? Just change the run= to: run="/bin/ld $ldargs $ofiles $ldlibs $extralib $startoff $libc" That's all. All program's cc'd thru ccc will have the -F option when you do a file on the executable. Somewhere in the manuals I've read that everything for ld must before /lib/crt0s.o /lib/shlib.ifile in order for -F to work. Also, -F is the most natural format for the machine because the object code is loaded by modulo 4096 (the page frame size). Read the man page for ld. -- JL Gomez
jrmacmillan@lily.waterloo.edu (John R. MacMillan) (08/08/88)
In article <422@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes: |I'd like to know what the -F ld option really does, and why it's |useful. When you RTFM for ld(1), you see "-F: like -z but takes less |disk space and can page faster into memory [...] The -F option is on |by default" (User's Manual, Vol II). But I know that the -F option is |NOT on by default. I came across a bin file for which "file" said |"(shared demand paged with shared library) -F (0413 demand paged)". |The man page, under the FILES section, lists /lib/ifile.0413-F, but |there is no such file in MY /lib. What's the deal here? As near as I can tell, it's the "default" if you put /lib/crt0s.o /lib/shlib.ifile _AFTER_ the other objects on the ld command line. I think the idea behind it is that the text and data sections are set up so that they can be paged into memory directly from the a.out. I don't know if this is really any faster or not. Anybody ever done any timings? |Note to CCC script writers: If we can really link using -F, and it's |really better than the default (-z, apparently), then why not fix CCC |to give ld the -F option unless contraindicated? One called "ccs" does this (that's where I learned the trick), and I changed my copy of ccc. -- John R. MacMillan jrmacmillan@lily.waterloo.edu If the universe fits, wear it. ..!watmath!lily!jrmacmillan
jrmacmillan@watdragon.waterloo.edu (John R. MacMillan) (08/29/88)
[ I posted this before, but I don't think it made it offsite. Apologies if you've seen it before. -- JRM ] In article <424@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes: |What appears to matter is the relative order of the .o |files and the startup file (crt0.o or crt0s.o) on the command line. | |I wrote a little test program, the usual "hello world!" routine. |After getting it debugged (with sdb, of course :-), I first did: | | [ Test and results deleted ] | |What the difference in times means, I don't know. Might be |interesting to test this with larger programs. But you can see that |when the startup routine appears LAST on the command line, you get |the -F executable, when it's FIRST on the command line, you get the |"normal" executable. Similar behavior when using the shlib. | |I used dump(1) on sfoo (slow foo) and ffoo (fast foo). The only |difference I could find was in dump -o: | |% dump -o sfoo ffoo | | [ dump output deleted ] | |This corresponds to a difference in entry (cf. UNIX System V |Programmer's Guide, COFF, p. 18-14), the entry point of the file. | |I still find this state of affairs bizarre, to say the least. Can a |14-byte variation in entry point really make that much difference in |loading/paging performance? Maybe I'll try re-linking Gnu Emacs this |new way to see if it loads faster. Don't bother. All you've done in the above test is find a way to trick the file(1) command. I was curious about all this too, and did a similar test, but when I dumped the "-F" one, I expected to find that it would have "virtual text and data starting addresses equal to the file offsets ... modulo 4096" (the ld(1) man page). No such addresses. Why then did file(1) say -F? A peek in /etc/magic showed that file says it's -F if the entry point is greater than 0x80000. Well, putting stuff before crt0 makes this true, and "tricks" file. So it's back to the drawing board. Does anyone have the missing /lib/ifile.0413-F? Is anyone enough of an ld wizard to recreate it? (I can only come as close as understanding ifile.0413). Sorry to be the bearer of bad news. -- John R. MacMillan jrmacmillan@dragon.waterloo.edu If the universe fits, wear it. ...!watmath!dragon!jrmacmillan