[I'm sending this twice, if you happen to have a MIME mailer, it's so
much nicer :-]

Hi,

First, yes several people have pointed my error vis:

Excerpts from mail: 16-Jun-94 Re: Unusual N_TXTADDR() ... Paul
Kranenburg@cs.few.e (1260)

> Actually, N_TXTADDR will evaluate to 0 only on old ZMAGIC files (like
> those that were in use by 386bsd).

I was wondering about this, executables should leave page 0 out.

Any way, some more on:

Excerpts from mail: 16-Jun-94 Unusual N_TXTADDR() ... =>
tech-kern@sun-lamp.cs (1084)

> while all others  (including .o files with OMAGIC) have a N_TXTADDR of
> __LDPGSZ (4096)

I then went on to state:

> so LD, when manipulating object files, just subtracts this mysterious 4k
> off again (yuck)!

I'll expand on this a little.  But first, I should note that in this
discussion I'm only considering simple object files i.e the stuff that
comes out of an assembler during a simple compile/assemble/link.

When LD reads in object files (because N_TXTADDR is 4k out) it defines
the macro TEXT_START such that the 4k is subtracted.  Having done this,
the code to manipulate relocations and symbols becomes easy.  Everything
in the loaded object file again has a consistent base address.

In the GNU tools, for NetBSD.386, there isn't this hack.  (BFD with
other A.OUT/OMAGIC object files assumes the text offset is 0.) The
consequence being that for gnu's objdump (b is a branch instruction :-),
given the code:

    .text
    .globl a
    .extern b
    a: b b

produces:

    Disassembly of section .text:
    00001000 <a+1000> b     00001000 <a+1000>

While what I would have expected was:

    Disassembly of section .text:
    00000000 <a> b  00000000 <a>

I'm aware of two ways that I can fix this:

    1.      Put the NetBSD 4k hack into the bfd config files

    2.      Argue that for simple unlinked object files (any
        possibly a few other cases) N_TXTADDR should return 0.

        		Comments?  Andrew

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.

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