[I'm sending this twice, if you happen to have a MIME mailer, it's so much
nicer :-]<nl>
<nl>
Hi,<nl>
<nl>
First, yes several people have pointed my error vis:<nl>
<nl>
<bold><excerpt>Excerpts from mail: 16-Jun-94 Re: Unusual N_TXTADDR() ...
Paul Kranenburg@cs.few.e (1260)</excerpt></bold><nl>
<nl>
<excerpt>Actually, N_TXTADDR will evaluate to 0 only on old ZMAGIC files
(like those that were in use by 386bsd).<nl>
</excerpt><nl>
I was wondering about this, executables should leave page 0 out.<nl>
<nl>
Any way, some more on:<nl>
<nl>
<bold><excerpt>Excerpts from mail: 16-Jun-94 Unusual N_TXTADDR() ... =3D>
tech-kern@sun-lamp.cs (1084)</excerpt></bold><nl>
<nl>
<excerpt>while all others  (including .o files with OMAGIC) have a
N_TXTADDR of __LDPGSZ (4096)<nl>
</excerpt><nl>
I then went on to state:<nl>
<nl>
<excerpt>so LD, when manipulating object files, just subtracts this
mysterious 4k off again (yuck)!<nl>
</excerpt><nl>
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.<nl>
<nl>
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.<nl>
<nl>
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:<nl>
<nl>
<example>.text<nl>
.globl a<nl>
.extern b<nl>
a: b b<nl>
<nl>
</example>produces:<nl>
<nl>
<example>Disassembly of section .text:<nl>
00001000 <lt>a+1000> b     00001000 <lt>a+1000><nl>
<nl>
</example>While what I would have expected was:<nl>
<nl>
<example>Disassembly of section .text:<nl>
00000000 <lt>a> b  00000000 <lt>a><nl>
<nl>
</example>I'm aware of two ways that I can fix this:<nl>
<nl>
<leftindent><description>1.	Put the NetBSD 4k hack into the bfd config
files<nl>
<nl>
2.	Argue that for simple unlinked object files (any possibly a few other
cases) N_TXTADDR should return 0.<nl>
</description><nl>
</leftindent>			Comments?  Andrew<nl>
<nl>
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.<nl>

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