[TUHS] ed.c on Unix v5

[TUHS] ed.c on Unix v5

[Noel Chiappa]

    > From: Mark Longridge

    > Not too sure about reversing getpid.o, but maybe possible with db?

Well, me, I'd just use 'od' - but then again, I have ucode for disassembling
PDP-11 octal! :-) (OK, OK, so a lot of the less common instructions I have
to look up! :-)

But, seriously, yeah, 'db' is probably the way to go.

FWIW, it's possible to get 'adb' running under V6 without much (any?) work,
too. Although maybe it needs the 'phototypesetter' C compiler? I'd have to
check...

There's also a 'cdb' running around (I found a copy on the 'Shoppa disks'),
which is basically 'db' but augmented with a few useful commands - maybe stack
backtrace, I don't recall the details, the documentation in on my V6, and I
don't feel like spinning it up just to look for that.

	Noel

[TUHS] ed.c on Unix v5

[Noel Chiappa]

    > From: Random832

    > Not quite. On a stock V6 kernel, system call 30 (smdate/utime) maps to
    > nullsys rather than nosys.

Oh, right. (Hadn't checked the number, assumed they used a new one for utime.)

	Noel

[TUHS] ed.c on Unix v5

[Noel Chiappa]

    > From: Random832

    > Non-existent syscalls map to nosys, which sets u_error to 100 ... which
    > causes the process to be sent a signal SIGSYS.

Oh, right, I'd forgotten that.

So, getting back to v6tar, I'll bet that if you try and use it to _read_ a TAR
file file under V6 (i.e. write files into the V6 filesystem), it will bomb out
(because of the call to utime).

     Noel

[TUHS] ed.c on Unix v5

[Random832]

Noel Chiappa writes:
> So, getting back to v6tar, I'll bet that if you try and use it
> to _read_ a TAR file file under V6 (i.e. write files into the
> V6 filesystem), it will bomb out (because of the call to
> utime).

Not quite. On a stock V6 kernel, system call 30 (smdate/utime)
maps to nullsys rather than nosys.

[TUHS] ed.c on Unix v5

[Noel Chiappa]

    > From: Mark Longridge <cubexyz at gmail.com>

    > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object
    > file getpid.o

Library, schlibrary! The important question is 'is it in the kernel source'?
(Although now that I think about it, if the library routine tries to use a
non-existent system call, it should return an error. It would be interested
to disassemble the library routine, and see what it thinks it is doing.)

   Noel

[TUHS] ed.c on Unix v5

[Mark Longridge]

> Library, schlibrary! The important question is 'is it in the kernel source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)
>
>   Noel

It does appear to be there:

looking in V5/usr/sys/ken/sys4.c starting at line 79:

getpid()
{
        u.u_ar0[R0] = u.u_procp->p_pid;
}

But looking at V4/nsys/ken/sys4.c it's not there. Not too sure about
reversing getpid.o, but maybe possible with db?

Mark


On 12/19/15, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Mark Longridge <cubexyz at gmail.com>
>
>     > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the
> object
>     > file getpid.o
>
> Library, schlibrary! The important question is 'is it in the kernel
> source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)
>
>    Noel
>

[TUHS] ed.c on Unix v5

[Mark Longridge]

Ok, not sure if anyone will want to do this but I've just compiled
ed.c from Unix v6 on Unix v5.

It's not much bigger than the assembled ed, with 1314 lines of C code
the compiled executable is only 6518 bytes vs 4292 for the original. I
was looking at the source code and didn't see anything that the v5 cc
couldn't handle. I trimmed the source a bit, there's a function at the
end called getpid()  which is commented out.

The comment says:

/* Get process ID routine if system call is unavailable. */

but my version of v5 does have that system call so it's all good.

It's been run a few times and it seems to work just fine. It may even
have a few more features than the v5 ed, I'm not sure yet :)

Mark

[TUHS] ed.c on Unix v5

[Dave Horsfall]

On Thu, 17 Dec 2015, Mark Longridge wrote:

> It's not much bigger than the assembled ed, with 1314 lines of C code 
> the compiled executable is only 6518 bytes vs 4292 for the original. I 
> was looking at the source code and didn't see anything that the v5 cc 
> couldn't handle. I trimmed the source a bit, there's a function at the 
> end called getpid()  which is commented out.

If your V5 has getpid(), then it's a...  strange version...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] ed.c on Unix v5

[Mark Longridge]

>> I trimmed the source a bit, there's a function at the
>> end called getpid()  which is commented out.

> If your V5 has getpid(), then it's a...  strange version...

I went back to the original uv5swre.zip file which was what I started
with and had another look to be sure.

It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
'ar t getpid.o' you can see the object file getpid.o

There's no other trace of getpid in v5 as it's not in the v5 manual
and there's no getpid.s in the disk image. I'm not sure if having
getpid in v5 is anomalous or not, perhaps you or someone else can
actually remember as I'm a johnny-come-lately to the party.  There's
even some commands mentioned in the v4 manual that don't exist in the
v5 disk image.

It's possible that there's another Unix v5 that really doesn't have
it, perhaps an older one.

Mark





On 12/18/15, Dave Horsfall <dave at horsfall.org> wrote:
> On Thu, 17 Dec 2015, Mark Longridge wrote:
>
>> It's not much bigger than the assembled ed, with 1314 lines of C code
>> the compiled executable is only 6518 bytes vs 4292 for the original. I
>> was looking at the source code and didn't see anything that the v5 cc
>> couldn't handle. I trimmed the source a bit, there's a function at the
>> end called getpid()  which is commented out.
>
> If your V5 has getpid(), then it's a...  strange version...
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>

[TUHS] ed.c on Unix v5

[Random832]

Mark Longridge <cubexyz at gmail.com> writes:

>>> I trimmed the source a bit, there's a function at the
>>> end called getpid()  which is commented out.
>
>> If your V5 has getpid(), then it's a...  strange version...
>
> I went back to the original uv5swre.zip file which was what I started
> with and had another look to be sure.
>
> It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
> 'ar t getpid.o' you can see the object file getpid.o

Plus, you know, the syscall itself.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sys4.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sysent.c

There are four (well, five with ctime) objects in libc.a with no
matching source file in /usr/source/s4: alloc, getpid, ladd, and
snstat.  Also, mon and qsort have assembly versions in s3 and C
versions in s4, and ctime is in s3 despite the fact that almost
every other libc file is in s4.

jnc at mercury.lcs.mit.edu (Noel Chiappa)
writes:

>     > From: Mark Longridge <cubexyz at gmail.com>
>
>     > if one looks at /lib/libc.a via 'ar t getpid.o' you can see the object
>     > file getpid.o
>
> Library, schlibrary! The important question is 'is it in the kernel source'?
> (Although now that I think about it, if the library routine tries to use a
> non-existent system call, it should return an error. It would be interested
> to disassemble the library routine, and see what it thinks it is doing.)

getpid.o consists of two instructions: sys getpid; rts pc. So it
unconditionally returns whatever the syscall puts in r0.

Non-existent syscalls map to nosys, which sets u_error to 100
(so, in principle, it will return 100, but), which causes the
process to be sent a signal SIGSYS.

[TUHS] ed.c on Unix v5

[John Cowan]

Mark Longridge scripsit:

> There's no other trace of getpid in v5 as it's not in the v5 manual
> and there's no getpid.s in the disk image. I'm not sure if having
> getpid in v5 is anomalous or not, perhaps you or someone else can
> actually remember as I'm a johnny-come-lately to the party.  There's
> even some commands mentioned in the v4 manual that don't exist in the
> v5 disk image.

The manuals were versioned, but the tapes were not: each tape represents
a snapshot of the research system on that particular day, so what you find
there isn't closely correlated with any manual version.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net

[TUHS] ed.c on Unix v5

[Craig Lennox]

On Dec 19, 2015, at 11:18, John Cowan <cowan at mercury.ccil.org> wrote:
> The manuals were versioned, but the tapes were not: each tape represents
> a snapshot of the research system on that particular day, 

Can we at least tell which day?

Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151219/422a4516/attachment.html>

[TUHS] ed.c on Unix v5

[Random832]

Craig Lennox <clennox at cosmic.com> writes:
> Can we at least tell which day?
>
> Craig

Assuming the clocks were set correctly, then to the extent it's
relevant, it'd be the latest timestamp. In Dennis_V5, that is the
kernel (and specifically conf.c, low.s, and mch.s as the most
recently modified source files), on Mar 21 1975.

The next newest files are dump, restor, and (kernel source) rkf.s
and nami.c... but there's no associated object file or change to
lib2.  The latest objects in lib1 and lib2 (and therefore
presumably the kernel) are:

lib1: sysent.o and sys4.o (Nov 21 1974) / maybe this change is getpid?
lib2: kl.o (Dec 2 1974)

[TUHS] ed.c on Unix v5

[Marc Rochkind]

Right. Obviously Doug can supply the details, but I recall that around 1972
or so Dick Haight used to go over from Piscataway to Murray Hill to get a
new system, and there would be some sort of indication about whether it was
a good day or a bad day to make a tape.

--Marc

On Sat, Dec 19, 2015 at 9:18 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Mark Longridge scripsit:
>
> > There's no other trace of getpid in v5 as it's not in the v5 manual
> > and there's no getpid.s in the disk image. I'm not sure if having
> > getpid in v5 is anomalous or not, perhaps you or someone else can
> > actually remember as I'm a johnny-come-lately to the party.  There's
> > even some commands mentioned in the v4 manual that don't exist in the
> > v5 disk image.
>
> The manuals were versioned, but the tapes were not: each tape represents
> a snapshot of the research system on that particular day, so what you find
> there isn't closely correlated with any manual version.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Long-short-short, long-short-short / Dactyls in dimeter,
> Verse form with choriambs / (Masculine rhyme):
> One sentence (two stanzas) / Hexasyllabically
> Challenges poets who / Don't have the time.     --robison who's at texas
> dot net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151219/5832b5b4/attachment.html>