Dave Huang <khym@bga.com> wrote:

>with both NetBSD's as running natively on mac68k and gas 2.9 running as
>a cross-assmebler on an i386. In fact, while the actual .o files aren't
>identical (why not? Are there timestamps in there or something?), the
>output of objdump -d on the .o files is identical.

There is a timestamp in the first record of a COFF file.  I don't know 
about the .o output of NetBSD's tools, but other systems that use COFF 
format generate data in host byte-order format.  (That and the timestamp 
would explain why your compare of files generated on mac68k and i386 are 
different.)  It's up to the tools that use the COFF files to figure this 
out and do the byte-swapping if the objects came from a host with a 
different byte order.  There's a flag in the first record of the file 
that indicates the byte order for the data sections of the file, but it's 
up to the tool to determine which byte order is used on the non-data 
records (Hdr, Ahdr, Reloc, Sect, etc). Since the first word of the file 
is a "magic short int" that only contains an 8-bit value I think it can 
be used to determine non-data record byte order. At least it seems to 
work for me in all the tools I've written dealing with them.

Now this may not apply to NetBSD but that's the way it works with TI's 
DSP tools, and I've successfully used the COFF file definitions from 
NetBSD to decypher them and write utilites dealing with files generated 
by their tools on various platforms. 

-bob