[TUHS] v6 debugging

[clemc@ccc.com (Clem Cole)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

below...

On Sat, Jan 23, 2016 at 11:58 AM, Will Senn <will.senn at gmail.com> wrote:

> All,
>
> I'm finally returning to my study of v6 after digging a bit further into
> assembly language and "other" pdp-11 operating systems. I even managed to
> get hello, world working in assembly in v6 and interestingly enough, I
> actually see how it works... for the most part :). Mini-note here:
>
>
> http://decuser.blogspot.com/2016/01/hello-world-in-assembly-on-research.html
>
> My question for y'all today is as follows (asked previously with a much
> larger gap in understanding):
>
> How did folks debug assembly routines in Unix v6, back in the day?
>

​3 questions here... how did you debug the pre-boot world (aka standalone
system), how to debug the kernel itself and a user program.

​
​Couple of them that I used were:


   1. T.lights&switches in the PMS notation (ie. the front console of the
   processor) - very helpful for kernel debugging.  In fact, certain patterns
   were definitely recognizable.   Plus people wrote programs the ran specific
   patterns in the console during certain times like the idle loop.  For the
   11 this was definitely used to debug the preboot world but it helped on the
   kernel (see below)
   2. printf or equiv
   3. a debugger when possible (adb came from AT&T, there is a ddt clone on
   one of the USENIX tapes - which I liked better and IIRC adb is not around
   with v5).  When I was mostly using v6, we used the ddt program, because I
   was also doing PDP-10 and a little VMS programming at CMU.   When I left
   CMU,went the V7 and later BSD 4.x and became pretty much 100% Unix, the ddt
   program had issues including no Vax port, so instead of fixing it, I learn
   adb and never went back.


In fact to help debug the kernel, we even put adb into the core resident
port of V7 which was tricky - Noel I seem to remember we (probably Steve
Zimmerman or maybe Geoff Peck) stole that from you guys at MIT (Steve
definitely spliced adb into the Masscomp kernel say in '84ish.  But I
remember having had something before that.

Clem

Side bar --- most of the Masscomp HW team came from the 780, 750 or 11/34
teams at DEC.   Dave Cane (Mr. 750), was the HW lead.   I remember a big
argument at Masscomp because the SW team wanted a real console at least as
a option and Dave hated them (for system debugging).  The best we ever got
was a set of macros for a logic analyzer hanging off of system in Eric
Finger's office.






>
> I realize that most folks didn't do assembly, but some did and I'm curious
> what their approach might have been.
>
​Use the USENIX Macro-11 assembler clone.

Funny, we were talking about this at lunch just yesterday!!  Later with the
Vax, post DEC putting the Fortran on BSD, ​you had the VMS linker on BSD.
Its still there and works.




>
> After having worked with RT-11 for a bit, I can see how I might develop
> using RT-11 and then "port" a program across, but that seems less than
> ideal. Here is my short list of missing features as I see them:
>
> 1. No listing file/cross reference list created by as.
>
​Check the USENIX tapes​




> 2. No map file created by ld.
>
​Yup - I never had one for the 11.

I seem to remember somebody (* Goble at Purdue I think) hacked a ld to
generate them.   Check USENIX and Purdue tools.   George's Microprocessor
tools for the Z80, 8080, 6800, 6502 etc... had an ld that did just this.



> 3. No debugger that I can find.
>
​From research, until V7 correct.  But check the USENIX tapes, ​Harvard, CU
or Columbia did a ddt clone that was pretty good.



> 4. This is not a missing feature, but it deserves inclusion in the list,
> the command as has possibly the most terse error messages

​No ed(1) has beats it.   You just get a ? printed.   Google "Brian
Kernightan's dashboard"  ​


​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160123/24561e77/attachment.html>