troxell@dinl.uucp (peter troxell) (01/27/89)
I am interested in finding out what the data structure is in the a.out file that has been dynamically linked between the end of procedure instructions in the text segment and the recognized end as reflected in the value of _etext symbol. I have examined both the a.out.h and exec.h include files along with the man entries for ld, and a.out. None seem to indicate what is the data that resides there. My initial guess is that it is some sort of initialization data for the dynamic loader to inform it as to locations where libraries can be loaded. Is this true? Thanks.. Peter Troxell NET: ncar!dinl!troxell US-MAIL: Martin Marietta I&CS, MS XL0402, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 977-2765 -- Peter Troxell NET: ncar!dinl!troxell US-MAIL: Martin Marietta I&CS, MS XL0402, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 977-2765
guy@auspex.UUCP (Guy Harris) (01/27/89)
>I am interested in finding out what the data structure is in the a.out >file that has been dynamically linked between the end of procedure >instructions in the text segment and the recognized end as reflected in >the value of _etext symbol. "Dynamically linked". Are you, perhaps, referring to SunOS 4.0 dynamic linking? If so, you should have said so, because not all readers would necessarily have been able to infer that.... >I have examined both the a.out.h and exec.h include files along with >the man entries for ld, and a.out. None seem to indicate what is the >data that resides there. Well, if you *are* referring to SunOS 4.0 dynamic linking, "exec.h" won't help you; the kernel doesn't know beans about SunOS 4.0 shared libraries. "a.out.h" probably won't help you either, for much the same reason. The data structures used by the run-time loader are, from the point of view of "exec", just stuff that's part of the data to be loaded from the executable image (I don't remember whether it's part of the "text segment", part of the "data segment", or both); it can't distinguish between those data structures and code or initialized data. >My initial guess is that it is some sort of initialization data for the >dynamic loader to inform it as to locations where libraries can be loaded. >Is this true? Again, if it's SunOS 4.0, and "locations where libraries can be loaded" refers to addresses in the process's address space where the text and data from the shared library can be placed, this is definitely *not* true - the run-time loader doesn't choose where to place shared libraries, it just tells the kernel "put this where you think it should go" and the kernel tells the run-time loader where they were put. (See MMAP(2).) Unfortunately, there is at present no documentation on the data structures used by the run-time loader.
frank@Morgan.COM (Frank Wortner) (01/31/89)
In article <900@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: > >Unfortunately, there is at present no documentation on the data >structures used by the run-time loader [in SunOS 4.0]. Well, "man 5 link" will get you a little information --- not enough, but a little. -- Frank uunet!s5!frank -or- frank@morgan.com "Computers are mistake amplifiers."
guy@auspex.UUCP (Guy Harris) (02/02/89)
>Well, "man 5 link" will get you a little information --- not enough, >but a little. And it will refer to you "/usr/include/link.h", as Rob Gingell pointed out to me. Note, however, that it also points out: BUGS These interfaces are under development and are subject to rapid change. which means what it says - this stuff may change in future releases.
jim@athsys.uucp (Jim Becker) (02/03/89)
I didn't see the original question, but from the title I would assume standard a.out format. On my system (Sun 3/60) 'man a.out' does it! -Jim Becker ...!sun!athsys!jim
guy@auspex.UUCP (Guy Harris) (02/08/89)
For additional information on SunOS dynamic linking and shared libraries, check "Shared Libraries", which is chapter 4 in the "Programming Utilities and Libraries" document in the SunOS 4.0 documentation set, and "Shared Libraries in SunOS" in the Summer 1987 USENIX Conference Proceedings.