9 Dec
2015
9 Dec
'15
4:53 a.m.
From: Will Senn <will.senn(a)gmail.com>
The problem is this, when I attempt to execute the
v6tar binary on the
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large
That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's causing
the
ENOMEM.
Noel
9 Dec
9 Dec
2:38 p.m.
New subject: v6tar from v7 on v6, too large?
On 12/8/15 10:53 PM, Noel Chiappa wrote:
That was it. Thanks for supplying the logic trail you followed as well!
I "upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate
SimH commands and then I folllowed the instructions in Setting up Unix
Sixth Edition to use the m45.s assist and voila, v6tar works. Thank you.
Now, when you say dump the a.out header, how do you do that?
Thanks,
Will
From: Will
Senn <will.senn(a)gmail.com>
The problem is this, when I attempt to execute
the v6tar binary on the
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large
That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's causing
the
ENOMEM.
Noel 
2:56 p.m.
New subject: v6tar from v7 on v6, too large?
dd if=v6tar bs=128 count=1 | od
check the man page on the a.out format.
BTW: I would relink v6tar to be a "407" header so it will run anywhere.
That said, there are a number of copies of v6tar "in the wild" - my memory
is that it's on a late 1970's, very early 1980s USENIX tape.
On Wed, Dec 9, 2015 at 9:38 AM, Will Senn <will.senn(a)gmail.com> wrote:
On 12/8/15 10:53 PM, Noel Chiappa wrote:
That was it. Thanks for supplying the logic trail you followed as well! I
"upgraded" to a 11/70 w/2M of RAM and FPP by passing the appropriate SimH
commands and then I folllowed the instructions in Setting up Unix Sixth
Edition to use the m45.s assist and voila, v6tar works. Thank you.
Now, when you say dump the a.out header, how do you do that?
Thanks,
Will
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
From:
Will Senn <will.senn(a)gmail.com>
The problem is this, when I attempt to execute
the v6tar binary on
the
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large
That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes
from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation
is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's
causing the
ENOMEM.
Noel
3:07 p.m.
New subject: v6tar from v7 on v6, too large?
On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc(a)ccc.com> wrote:
check the man page on the a.out format.
Note to folks on the list - please don't give away the answer...
Will
A small piece of homework for the student -- look at 407 the magic number
for the a.out file and see if you can explain why Ken picked that value.
Hint it is particular to the PDP-11 architecture and is not portable to
other systems, although most other systems that UNIX was "ported" too
continued to used the a.out format kept the magic numbers as 407/411 etc.,
although I know of some ports (like mine own for Magix - the Tek Magnolia
system of the late 1970s) that changed the magic number to be correct for
that architecture.
Clem
4:29 p.m.
New subject: v6tar from v7 on v6, too large?
On 12/9/15 9:07 AM, Clem Cole wrote:
On Wed, Dec 9, 2015 at 9:56 AM, Clem Cole <clemc(a)ccc.com
<mailto:clemc@ccc.com>> wrote:
check the man page on the a.out format.
Note to folks on the list - please don't give away the answer...
Will
A small piece of homework for the student -- look at 407 the magic
number for the a.out file and see if you can explain why Ken picked
that value. Hint it is particular to the PDP-11 architecture and is
not portable to other systems, although most other systems that UNIX
was "ported" too continued to used the a.out format kept the magic
numbers as 407/411 etc., although I know of some ports (like mine own
for Magix - the Tek Magnolia system of the late 1970s) that changed
the magic number to be correct for that architecture.
Clem
Clem,
Nice!
In full disclosure, I read about magic numbers being PDP architecture
related somewhere in the recent past, but I didn't really understand the
connection. So, when you mentioned it, rather than google it and spoil
the fun, I took the hint and thought a bit about it in the context of
our discussion. As it turns out, according to my now handy-dandy
PDP11/40 processor handbook, the 18 bits holding the word 000407 which
appears as the first word of most of my v6 binaries, 000 000 100 000
111b, the magic number represents the BR instruction base where the last
8 bits is an offset added to the PC after it has read the word. So, the
PDP loads the object, reads the first word, determines it is a branch
instruction:
BR PC+7
and jumps forward to start reading the 9th word of the program. Why the
9th word? According to man 5 a.out, the a.out header always contains 8
words.
So, given a binary, like write:
dd if=write bs=128 count=1|od
1+0 records in
1+0 records out
0000000 000407 001176 000032 000150 000000 000000 000000 000001
0000020 022627 000002 001412 003006 012700 000001 104404 000657
...
The analysis that follows in light of the information discovered so far
would be:
word 1 at 0000000 000407 Magic Number (BR PC+7)
word 2 at 0000002 001176 Size of the program text segment (638 bytes)
word 3 at 0000004 000032 Size of the initialized data segment (26 bytes)
word 4 at 0000006 000150 Size of the uninitialized data segment (104 bytes)
word 5 at 0000010 000000 Size of the symbol table (stripped in this case)
word 6 at 0000012 000000 The entry location 0 at present
word 7 at 0000014 000000 Unused
word 8 at 0000016 000001 Relocation bit suppression flag (I think this
means the file contains absolute memory references)
word 9 at 0000020 022627 The target of the first branch, contains
instructions to MOV (R6)+,(R7)+ (I think)...
According to man 5 a.out on v7, the different magic numbers represent
normal, read-only text, separate I&D, and overlay:
#define A_MAGIC1 0407 /* normal */
#define A_MAGIC2 0410 /* read-only text */
#define A_MAGIC3 0411 /* separated I&D */
#define A_MAGIC4 0405 /* overlay */
This means that branches are to 9th, 10th, 11th and 7th words,
respectively. It'll be a while before I really understand what the
ramifications are.
Oh and by the way, jumping between octal and decimal is weird, but
convenient once you get the hang of it - 512 is 1000, which is nifty and
makes finding buffer boundaries in an octal dump easy :).
Thanks,
Will
2:59 p.m.
New subject: v6tar from v7 on v6, too large?
On Mi, 2015-12-09 at 08:38 -0600, Will Senn wrote:
Now, when you say dump the a.out header, how do you do
that?
Apply OD(1) to the executable. You can then inspect the
exec header, especially the magic number, in order to
investigate the startup of the program.
Hellwig
5:55 p.m.
New subject: v6tar from v7 on v6, too large?
On 12/8/15 10:53 PM, Noel Chiappa wrote:
Noel,
I followed the thread you provided and I appreciate the direction.
estabur(who thought these names up, I know 8 characters is limiting, but
c'mon) is indeed the culprit:
if(sep) {
if(cputype == 40)
goto err;
I'm gathering (read still investigating) that the 411 header is read by
a loader and the call to estabur is made with a value for sep indicating
that it is a split I+D binary, then the cputype is checked and sure
enough, it's a PDP-11/40 and the error is generated.
Thanks,
Will
From: Will
Senn <will.senn(a)gmail.com>
The problem is this, when I attempt to execute
the v6tar binary on the
v6 system (it works in v7) it errors out:
v6tar
v6tar: too large
That's an error message from the shell; the exec() call on the command
('v6tar') is returning an ENOMEM error. Looking in the kernel, that comes from
estabur() in main.c; there are a number of potential causes, but the most
likely is that 'v6tar' is linked to be split I+D, and your V6 emulation is on
a machine that doesn't have split I+D (e.g. an 11/40). If that's not it,
please dump the a.out header of 'v6tar', so we can work out what's causing
the
ENOMEM.
Noel
3055
days inactive
3055
days old
6 comments
4 participants
participants (4)
-
Clem Cole -
Hellwig Geisse -
jnc＠mercury.lcs.mit.edu -
Will Senn