[TUHS] history of virtual address space

[Warner Losh via TUHS]

Looking at 4.2BSD sources, I don't see any offset for address 0. a.out
makes it kinda hard to unmap page 0. The compiler would have to put a start
address into the a.out header, and the 4 binaries I checked had an a_entry
of 0.. But it looks like only the stand alone programs use a_entry...  But
that's hidden as this inside setregs() in kern_exec.c:
        u.u_ar0[PC] = u.u_exdata.ux_entloc+2;
and that type puns to a.out's a_entry, so that's going to jump to 0.

4.3BSD spells it a little differently:
        setregs(exdata.ex_exec.a_entry);
but has the same a_entry == 0. setregs moved to vax/machdep.c where it adds
2.

So maybe my memory is bad, maybe we had a local hack. I acn't find out for
sure, but stock 4.3BSD/vax necessarily maps page 0.

Warner

On Tue, Jan 20, 2026 at 12:38 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Tue, Jan 20, 2026, 9:49 AM Rich Salz <rich.salz at gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 19, 2026 at 7:05 PM Warner Losh via TUHS <tuhs at tuhs.org>
>> wrote:
>>
>>> 4.2BSD on the Vax dereferencing 0 would seg fault. I'm not sure when this
>>> started. I am sure that System V or 32V on the Vax dereferencing 0 gave
>>> 0.
>>
>>
>> Are you sure?  My memory is the opposite.  For example,
>> https://www.tuhs.org/Usenet/comp.bugs.4bsd/1989-July/003016.html
>>
>
>
> Maybe it was a local hack. I know for sure that the vax assembler i wrote
> definitely core dump when i did *NULL... it may have been 4.3 by then... I
> also recall a prof or TA saying that 4.1BSD burned a lot of time on
> infinite loops that students wrote, but now they are core dumps... But I've
> not looked at the 4.3 sources to see if that's unmapped.
>
> Warner
>
>>
>>