Big "ld -F" disappointment

[John R. MacMillan]

With the discussion of placement of /lib/crt0[s].o on the ld
command line to get a -F file, I decided to look into why, and
what I came up with is that it doesn't really work.

According to the ld(1) man page, -F files have virtual addresses
equal to the file offsets modulo 4096.  Files compiled as above
don't.

So why does file(1) say it worked?  Because /etc/magic decides that
and object is -F if the _entry point_ is > 0x080000.  Putting
/lib/crt0.o _after_ other things makes this true, and thus tricks
the file(1) command.

The grisly details are included below.

So this brings us back to: how do we get a _real_ -F file? Has anyone
got a /lib/ifile.0413-F (this is what ld(1) looks for if you specify
-F)?  Is anyone enough of an ld(1) wizard to reconstruct it?

Here's the whole of my little test, with some comments:

$ cat foo.c
main()
{}
$ cc -c foo.c
$ ld -m foo.o /lib/crt0.o -lc
		LINK EDITOR MEMORY MAP


output		input		virtual
section		section		address		size

.text   			   80000	      6c
                                   ^^^^^
>> The text is starting at this address
		.text   	   80000	      14 foo.o
		.text   	   80014	      2c crt0.o
                                   ^^^^^
>> The entry point is around here, which will fool file(1)
		.text   	   80040	      18 libc.a
		.text   	   80058	      08 libc.a
		.text   	   80060	      0c libc.a

*avail*				   8006c	    ff94

.data   			   90000	      00	uninitialized

.bss    			   90000	      08	uninitialized
		.bss    	   90000	      08 crt0.o

*avail*				   90008	  26eff8
$ file a.out
a.out:		mc68k executable (shared demand paged) not stripped -F (0413 demand paged) 
$ dump -h a.out


			***SECTION HEADER***
	Name        Paddr       Vaddr       Scnptr      Relptr     Lnnoptr
	            Flags                    Size       Nreloc      Nlnno

a.out:
	.text     0x00080000  0x00080000  0x00000400  0x00000000  0x00000000
                                          ^^^^^^^^^^
>> This is the offset of the .text section in the file. This means that
>> the address for .text (above) should be 0x080400 for a -F file
	          0x00000020              0x0000006c        0           0

	.data     0x00090000  0x00090000  0x00000000  0x00000000  0x00000000
	          0x00000040              0x00000000        0           0

	.bss      0x00090000  0x00090000  0x00000000  0x00000000  0x00000000
	          0x00000080              0x00000008        0           0

Note that if you do "ld -m /lib/crt0.o foo.o -lc" you'll get exactly
the same map as above; ie. our -F file is the same as a normal one.

Oh well, back to the drawing board. :-(
-- 
John R. MacMillan
jrmacmillan at lily.waterloo.edu		If the universe fits, wear it.
...!watmath!lily!jrmacmillan