thad@cup.portal.com (Thad P Floryan) (12/31/90)
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? Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] -------------------- begin included material $ cat Makefile CC = gcc CFLAGS = -O LDFLAGS = -s LIBS = /lib/crt0s.o /lib/shlib.ifile doit : gcc $(CFLAGS) $(LDFLAGS) -shlib coff1.c -o coff1 gcc $(CFLAGS) $(LDFLAGS) coff2.c -o coff2 -shlib $(CC) $(CFLAGS) -c coff3.c $(LD) $(LDFLAGS) -o coff3 coff3.o $(LIBS) $(CC) $(CFLAGS) -c coff4.c $(LD) $(LDFLAGS) -o coff4 $(LIBS) coff4.o rm -f *.o ls -il coff1 coff2 coff3 coff4 file coff1 coff2 coff3 coff4 size coff1 coff2 coff3 coff4 $ ls -il total 45 6268 -rw-r--r-- 1 thad users 440 Dec 30 20:41 Makefile 6269 -rw-r--r-- 4 thad users 5258 Dec 30 20:29 coff1.c 6269 -rw-r--r-- 4 thad users 5258 Dec 30 20:29 coff2.c 6269 -rw-r--r-- 4 thad users 5258 Dec 30 20:29 coff3.c 6269 -rw-r--r-- 4 thad users 5258 Dec 30 20:29 coff4.c $ make gcc -O -s -shlib coff1.c -o coff1 gcc -O -s coff2.c -o coff2 -shlib gcc -O -c coff3.c ld -s -o coff3 coff3.o /lib/crt0s.o /lib/shlib.ifile gcc -O -c coff4.c ld -s -o coff4 /lib/crt0s.o /lib/shlib.ifile coff4.o rm -f *.o ls -il coff1 coff2 coff3 coff4 6317 -rwxr-xr-x 1 thad users 3116 Dec 30 20:46 coff1 6314 -rwxr-xr-x 1 thad users 3116 Dec 30 20:46 coff2 6305 -rwxr-xr-x 1 thad users 3116 Dec 30 20:47 coff3 4755 -rwxr-xr-x 1 thad users 3116 Dec 30 20:47 coff4 file coff1 coff2 coff3 coff4 coff1: mc68k executable (shared demand paged with shared library) coff2: mc68k executable (shared demand paged with shared library) coff3: mc68k executable (shared demand paged with shared library) \ -F (0413 demand paged) coff4: mc68k executable (shared demand paged with shared library) size coff1 coff2 coff3 coff4 coff1: 1476(.text) + 44(.data) + 0(.bss) + 0(.lib) = 1520 coff2: 1476(.text) + 44(.data) + 0(.bss) + 0(.lib) = 1520 coff3: 1476(.text) + 44(.data) + 0(.bss) + 0(.lib) = 1520 coff4: 1476(.text) + 44(.data) + 0(.bss) + 0(.lib) = 1520 -------------------- end included material
floyd@ims.alaska.edu (Floyd Davidson) (12/31/90)
In article <37414@cup.portal.com> thad@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'm not sure what it is *supposed* to mean, but what causes it is linking the startup code at a location other than the start of the text segment. The "-F (0413 demand page)" is from /etc/magic: >>36 long >0x80000 -F (0413 demand paged) What particular significance there is to this and what the '-F' might indicate I don't know. Floyd -- Floyd L. Davidson floyd@ims.alaska.edu Salcha, AK 99714 paycheck connection to Alascom, Inc. When I speak for them, one of us will be *out* of business in a hurry.
andy@cs.caltech.edu (Andy Fyfe) (01/01/91)
In article <1990Dec31.132708.5522@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: >The "-F (0413 demand page)" is from /etc/magic: > >>>36 long >0x80000 -F (0413 demand paged) The long at offset 36 is the entry field in the (optional, but ever present) a.out header (see aouthdr.h). Moving the startup file crt0 around is bound to affect this number; it's not clear what it might mean under more "controlled" circumstances. In any event, this has been deleted from the updated /etc/magic file in fix disk 2. My entry now looks like this (and it's been augmented to provide cpu and floating point types (the ">18" lines)): 0 short &0177770 0520 mc68k executable >18 short &0x1800 0x0000 [68010] >18 short &0x1800 0x0800 [68020] >18 short &0xe000 0x0000 [float-none] >18 short &0xe000 0x2000 [float-soft] >18 short &0xe000 0x4000 [68881] >18 short &0xe000 0x8000 [sky] >12 long >0 not stripped >2 short 4 {shared library} >0 short 0520 (impure) >0 short 0521 (shared) >0 short 0522 (shared demand paged) There's also a comment at the front that says: # 4/89 - JCM - Changed to correct identification of 68010 types Andy Fyfe andy@cs.caltech.edu
alex@umbc3.UMBC.EDU (Alex S. Crain) (01/01/91)
I didn't get this behavior on my machine (3.51m) but I can guess at whats going on (my file command is different, probably just /etc/magic). In article <37414@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: [Whats different about this?] > ld -s -o coff3 coff3.o /lib/crt0s.o /lib/shlib.ifile > gcc -O -c coff4.c > ld -s -o coff4 /lib/crt0s.o /lib/shlib.ifile coff4.o The difference here is in the order of the arguments. ld processes its arguments in order, so this counts. In the scond case (coff4), ld is doing the following actions: Turn stripping on Set the output file to coff4 load /lib/crt0s.o load /lib/shlib.ifile load coff4.o shlib.ifile is the magic file that tells ld how to position the segments and set things up for shared libraries. (Note: shared libraries are signaled by the presence of a 4th (.lib) section in the file. They can have any magic number, although shlib.ifile is configured fo In the former case (coff3), the loader starts creating the output file *brfore* it sees the loader directives, so it uses the default directives, 0413/-F. This sets up the text/data/bss sections for demand paging, which is not overridden when /lib/shlib.ifile is loaded later. shlib.ifile does add that special .lib section, though so everything works. Why -F? I'm thinking that specifying and ifile cancels the -F directive, which is on by default. Since the loader has to configure itself to load coff3, I would guess that it turns -F on as well. Whats seems odd to me is that on my machine, I get 0413 executables in all cases. I am using a hacked up shlib.ifile, though (which does the blocking and alignment line ifile.0413) so maybe thats it. In any case your shlib.ifile should look like this: ... SECTIONS { .text 0x80000 BLOCK(1024) : {} GROUP ALIGN(65536) BLOCK(1024) : { .data : {} .bss : {} .lib : {} } } ... This will give you demand paged binaries. NOTE: arguments to gcc are not order sensitive, so gcc -shlib always puts the /lib/crt0s.o /lib/shlib.ifile first when it invokes the loader, no matter where the -shlib appears in the argument list. -- ################################# :alex. #Disclaimer: Anyone who agrees # Systems Programmer #with me deserves what they get.# University of Maryland Baltimore County ################################# alex@umbc3.umbc.edu
john@chance.UUCP (John R. MacMillan) (01/02/91)
thad@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@chance.UUCP | Because guys with nicknames always get the gal. ...!scocan!chance!john | -- barenaked ladies