ld -F

John R. MacMillan jrmacmillan at watdragon.waterloo.edu
Mon Aug 29 03:39:59 AEST 1988


[  I posted this before, but I don't think it made it offsite.  Apologies
   if you've seen it before. -- JRM  ]

In article <424 at manta.pha.pa.us> brant at 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 at dragon.waterloo.edu		If the universe fits, wear it.
...!watmath!dragon!jrmacmillan



More information about the Unix-pc.general mailing list