Hi,

Excerpts from mail: 17-Jun-94 Re: More on unusual N_TXTAD.. =>
tech-kern@sun-lamp.cs (2089+0)

> PS:	Be careful when using binutils/objdump.386 as a reference point.  It
> appears (to me) that the BFD code fails to reconize NetBSD.386 object
> files and instead treats them as 386BSD ones.  More on this later.

NetBSD version:  NetBSD 0.9a (GENERICAHA) #9: Sat Apr 16 23:13:55 PDT 1994

Summary:

> Object files created by the NetBSD.386 assembler have their magic number
> in little endian order.  The linker then reads these object files and
> writes out an executable with a network byte ordered magic number.

My question: 

> Shouldn't the assembler be creating object files with the magic number
> in network byte order?

To illustrate this:

    cagney@bunyip$ uname -a
    NetBSD bunyip 0.9a GENERICAHA#9 i386
    cagney@bunyip$ cat s.s
    cagney@bunyip$ /usr/bin/as s.s
    cagney@bunyip$ od -X a.out
    0000000         00000107        ...

Or (if your haveing trouble standing on your head :-) on a big-endian SPARC:

    cagney@puddin$ uname -a
    SunOS puddin 4.1.3_U1 1 sun4c
    cagney@puddin$ od -X a.out
    0000000  07010000      ......

The header file /usr/include/a.out.h states:

> The a.out structure's a_midmag field is a network-byteorder encoding of
> this int
>       FFFFFFmmmmmmmmmmMMMMMMMMMMMMMMMM
> Where `F' is 6 bits of flag like EX_DYNAMIC,
>        `m' is 10 bits of machine-id like MID_I386, and
>       `M' is 16 bits worth of magic number, ie. ZMAGIC.
> The macros below will set/get the needed fields.

I suspect that this is a hangover of 386BSD.

		Comments?
					Andrew

PS: I'll only be fixing this in gas-2.3/binutils-2.4 where things are
even more stuffed...

------------------------------------------------------------------------------