> Or to translate (?) it:
> 
>     ZMAGIC files (pageable) have N_TXTADDR of 0 while all others
>     (including .o files with OMAGIC) have a N_TXTADDR of __LDPGSZ (4096)
> 
Actually, N_TXTADDR will evaluate to 0 only on old ZMAGIC files (like those
that were in use by 386bsd).

> The consequence of this is that symbol offsets in object files are all
> 4096 bytes short of the TXT addresses they refer to.
Object files as produced by `as' or `ld -r' are not meant to be executable,
thus it is pointless to attach meaning to the values of the N_TXT_*() macros
which refer to addresses when loaded in memory (for execution).

However, the OMAGIC number is overloaded as it is also in use for an
executable files (generated by `ld -N') in which case N_TXTADDR() refers
to the load address as expected by the kernel's execve(2).

> so LD, when manipulating object files, just subtracts this mysterious 4k
> off again (yuck)!
> 
This only applies to shared objects which have no fixed load address and
are linked as if their load address is 0. At run-time, additional relocation
is done based on the actual load address. Maybe, some day, ld will relocate
shared objects at __LDPGSZ like standard executables and leave the
adjustment to the run-time linker.

-pk

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