From: ldg@drbug3.dr.att.com (Doug Gibbons)
Newsgroups: comp.unix.wizards
Subject: Re: ISC V.3.2 COFF executables?
Keywords: object,coff,compatibility,shared libraries
Date: 13 Oct 92 20:48:16 GMT

In article <2391@adagio.lemis.uucp>, grog@lemis.uucp (Greg Lehey) writes:
|> I'm currently looking at emulation of COFF executables under BSD, and
|> have been examining the files supplied with ISC 2.2 (which is V.3.2).
|> According to the documentation I have, both from ISC and from O'Reilly
|> ("Understanding and Using COFF"), the main segment types of interest
|> for executable files are text, data, bss and library segments - this
|> last only when shared libraries are implemented.
|> 
|> I wrote a little program to examine the executables supplied by ISC
|> and found:
|> 
|> 1. A large number of executables have a library segment, though it is
|>    my understanding that ISC 2.2 does not support shared libraries.
|>    The library section usually consists of a 24-byte structure: {int,
|>    int, char [];}. The ints are small numbers (typically 6 and 2 or 7
|>    and 2), the char [] is a library name such as /shlib/libX11_s.v1.
|>    I have been unable to find these files on the system, though the
|>    executables work. Can anybody tell me:
|>        - the meaning of the digits
|>        - whether the pathname of the library should be considered to
|>          be absolute or relative.

On AT&T SVR3, the file name is an absolute path name of the target shared
library which is loaded by the kernel at exec time.

|>        - how the system survives the lack of these libraries.

If you're saying, "How can such a foreign a.out execute properly without
these libraries?", the only answer would seem to be that they're not executing
anything that was defined in the shared library. If you don't have the
shared libraries needed by an executable, there's little chance that you
can use it at all.

|> 
|> 2. In addition, many executables contain segments with flags 0x22 or
|>    0x42. Nearly all the X executables have:
|> 
|> /adagio/usr/bin/X11/xsetroot: 
|> unknown segment: name .fka000, type 22, load address a0000000, file address 0, size 19352
|> unknown segment: name .fka040, type 42, load address a0400000, file address 0, size 1576
|> unknown segment: name .fka080, type 22, load address a0800000, file address 0, size 96604
|> unknown segment: name .fka0c0, type 42, load address a0c00000, file address 0, size 26644
|> unknown segment: name .fka100, type 22, load address a1000000, file address 0, size 13788
|> unknown segment: name .fka140, type 42, load address a1400000, file address 0, size 1528

These are fake (.fk*) sections constructed by the linker.
The name of each one is derived from its load address.

Your a.out appears to be referencing 3 shared libraries - above
are fake sections for the .text and .data for each one. The
flags above - 22 == NOLOAD | TEXT, 42 == NOLOAD | DATA. AT&T's
386 convention is that 0xa0000000 - 0xa3c0000 is reserved for
loading /shlib/libc_s and /shlib/libnsl_s ( shared C and networking
libraries).


-- 
--------------------------------------------------------------------------------
-- Doug Gibbons			| ldg@druhi.att.com or att!druhi!ldg
-- AT&T Bell Laboratories 
-- Denver CO