Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!zephyr!tektronix!sequent!mntgfx!dclemans
From: dclemans@mentor.com (Dave Clemans @ APD x1292)
Newsgroups: comp.sys.apollo
Subject: Re: coff2bsd converter
Message-ID: <1989Jun21.195343.3631@mentor.com>
Date: 21 Jun 89 19:53:43 GMT
References: <650@wrs.UUCP>
Organization: Mentor Graphics Corporation, Beaverton Oregon
Lines: 33

From article <650@wrs.UUCP>, by geoff@wrswrs.UUCP (Geoff Espin):
> 
> Do I have to worry about the .rwdi section?  .inlib? .sri?
> This is on a SR10 3500 -- obviously the resulting object module
> is for a different machine & OS.
> 
> Any guidance greatly appreciated.
> 

The .mir section contains comments that state what versions of what
tools built the file; it can be ignored.

The .sri section says what environment the program expects; it's a
big part of the support for automatically switching operating system
environments.  As long as your consistent (all object files built
for bsd, or for sys5, ...) you should be able to to ignore .sri records.

The .inlib section is one of the mechanisms for doing automatic runtime
binding.  If you're not using these features the .inlib section should
be empty and thus ignorable.

The .lines, .blocks, .rwdi, etc. contains Apollo's notion of symbolic
debugging information (i.e. what the "-g" switch generates).  The last
I heard the formats of these sections are not yet public, though
obviously they are only needed for symbolic debuggers.

The other big area you will need to watch in the conversion are
relocatable text/data values.  Different systems have different conventions
over what types of relocations are accepted, what values (if any) memory
locations should hold before they are relocated, boundaries between text
and data, etc.

dgc