From mboxrd@z Thu Jan  1 00:00:00 1970
From: cubexyz@gmail.com (Mark Longridge)
Date: Sat, 19 Dec 2015 07:40:48 -0500
Subject: [TUHS] ed.c on Unix v5
In-Reply-To: <20151219121220.EC3A718C0A3@mercury.lcs.mit.edu>
References: <20151219121220.EC3A718C0A3@mercury.lcs.mit.edu>
Message-ID: <CADxT5N5iGFBdmfZtt5TeYN+xM1bKKAFUCALmEEP37VH-2h2qZg@mail.gmail.com>

> 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
>