[comp.sys.apollo] coff2bsd converter

geoff@wrswrs.UUCP (Geoff Espin) (06/19/89)

I'm working on a COFF to a.out (BSD) converter.
Does such a beast already exist?

I did a "coffdump -v -r -h -t file.o" and I see:

	...  .text, .bss, etc deleted ...

	.rwdi     0x0005a384  0x0005a384  0x0004b964  0x00000000  0x00000000
                  REG                     0x000040b8         0         0
                  RELOC_NOT_LOADED
 
        .blocks   0x0005e43c  0x0005e43c  0x0004fa1c  0x00000000  0x00000000
                  REG                     0x00017e7e         0         0
                  RELOC_NOT_LOADED, DEBUG

        .lines    0x000762bc  0x000762bc  0x0006789a  0x00000000  0x00000000
                  REG                     0x0000d87e         0         0
                  RELOC_NOT_LOADED, DEBUG

        .sri      0x00000000  0x00000000  0x00075118  0x00000000  0x00000000
                  INFO                    0x0000001c         0         0
                  

        .inlib    0x00000000  0x00000000  0x00075134  0x00000000  0x00000000
                  LIB                     0x00000004         0         0
                  

        .mir      0x00000000  0x00000000  0x00075138  0x00000000  0x00000000
                  INFO                    0x0000008c         0         0
                  

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.

---
Geoff Espin		geoff@wrs.com	(415)428-2623
Wind			River		Systems
1351 Ocean Avenue	Emeryville	CA 94608
-- 
---
Geoff Espin		geoff@wrs.com	(415)428-2623
Wind			River		Systems
1351 Ocean Avenue	Emeryville	CA 94608

dclemans@mentor.com (Dave Clemans @ APD x1292) (06/22/89)

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