Can you explain this shared lib anomaly? (3B1)

[John R. MacMillan]

thad at cup.portal.com (Thad P Floryan) writes:

|Can anyone explain the meaning of "-F (0413 demand paged) " as shown for the
|example of "coff3" below?  One thing I've noticed is the latest release of
|CTIX identifies all shlib-linked executables that way, but there's only ONE
|way to do this on the UNIXPC (per my example of "coff3" below).
|
|Something is obviously different; all 4 executables work; one of them is marked
|with the "something new and completely different" ``-F (0413 demand paged)''
|
|Anyone have any ideas?

I looked into this a few years ago when people first noticed that if
you built things certain ways file(1) gave this response.  I believe
that what I found then is still true.

Old versions of /etc/magic (and hence file(1)) report this if the
object's entry point (as identified in the COFF file) isn't the
first thing in the .text section.  One of the fixdisks changed this.
This would happen if /lib/crt0s.o wasn't the first thing that went
into .text.

The ld(1) man page lists a -F options which is: ``Like -z but takes
less disk space and can page faster into memory.  This type is also
indicated by magic number 0413 in the os header.  It is
distinguished by having virtual text and data starting addresses
that are equal to the file offsets of the text and data sections,
modulo 4096.  The -F option is on by default.''

So we can see why they would page faster into memory: the os could
grab the page right off disk and use it without having to shift it.

However, I also decided the man page lies.  None of the objects I
inspected had this property, and if I tried to explicitly use -F it
tried to use a non-existent ifile: "ifile.0413-F".  I concluded that
the real default was -z, which produces demand paged executables,
but not the fast ones described.

I seem to also recall that I convinced myself at the time that you
*couldn't* make an ifile.0413-F that did what you'd need to for the
documented -F behaviour, at least not without help from ld(1) that
isn't mentioned in the man page or the ``Link Editor'' section in
the programmers guide.  You should be able to get similar behaviour
(faster paging) at a cost of larger executables by forcing the
sections to begin on 4K boundaries, but this isn't quite what we're
after, and when I try it out now, it doesn't seem to work.

When I think about it now, I would think that you could do it with a
two-pass load, much like shcc/shld do, except that the first pass
would find the file offsets of the relevant sections and then build
a suitable ifile.  However, playing with this just now, I was unable
to get it to work.

So what's the end result?  IMHO, the -F executable is a myth.
-- 
John R. MacMillan       | I wish I had a nickname like Crusher, Snake or Dennis
john at chance.UUCP        | Because guys with nicknames always get the gal.
...!scocan!chance!john  |       -- barenaked ladies