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

[Alex S. Crain]

	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 at cup.portal.com> thad at 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 at umbc3.umbc.edu