[TUHS] v6 debugging

[TUHS] v6 debugging

[Noel Chiappa]

[TUHS] v6 debugging

[Noel Chiappa]

    > From: Clem Cole

    > 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 .. stole that from you
    > guys at MIT

Well, I certainly don't remember doing such a thing - but I should point out
that the Unix 'community' at MIT was not at all in good touch with each
other. So perhaps someone else at MIT did it? Or perhaps it was done after
I left for Proteon?

Also, the group I was in - CSR - was, during my time with them, not well
connected to other Unix users outside MIT. So even the things we _did_ do seem
not to have made it to many (any?) people. I'm not sure why this was:
probably, since we were working exclusively on early TCP/IP stuff, we were
mostly in touch with other networking people.

The disconnect to the rest of MIT may have been because, in our case, the
technical community at Tech Square didn't have good contacts with the rest of
campus; we were kind of self-sufficient. The AI Lab people had some contacts
with the Plasma fusion group, and later the EE department on campus, but CSR
(and maybe all of LCS - I'm not sure, the groups in LCS were pretty isolated
from each other) didn't.

Also, Tech Sq was mostly about PDP-10's - initially running ITS, later TWENEX
- and only a couple of smaller groups ran Unix. The DSSR group had an 11/70,
and we were quite close to them, but AFAIK we were the only two groups in Tech
Sq running Unix. I don't think anyone else at MIT had a PDP-10, until the EE
department on campus got an TWENEX machine, so there wasn't really anyone on
campus for most of Tech Sq to interact with.

	Noel

[TUHS] v6 debugging

[Clem Cole]

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

On Mon, Jan 25, 2016 at 10:12 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> Also, Tech Sq was mostly about PDP-10's - initially running ITS, later
> TWENEX
> - and only a couple of smaller groups ran Unix.
>

​In those days, I knew / knew of some of Steve Wards' guys in the RTS lab
working on Trix (Wayne Gramlich [late of CMU -- the connection], Jack Test,
Tom Teixeira, Terry Hayes, etc...).
Wayne brought some of the CMU hacks to MIT and sent us some of theirs such
as the Chaos code.   For instance, my >>guess<< is that fsck came to MIT
via that connect, since Ted wrote much of it at CMU.

FYI: I would later do a really crappy job of hacking the Ritchie C compiler
to work with an experimental chip we got from Moto (what would become the
68K) - it generated correct code (just barely) but worked.   It was from
that connect I learned that Ward's guys did a >>much<< better job for Trix
project (and maybe used the Johnson compiler - but could target a couple of
different micros).  I remember I switched to their compiler when I got it
(from Jack I think).  I believe I even still have 9-track tape of it
somewhere in my basement.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160125/a2fbac46/attachment.html>

[TUHS] v6 debugging

[Noel Chiappa]

    > From: Will Senn

    > I have cdb .. How do I exit it. %, CTRL-C, CTRL-D, CTRL-Z, Break,
    > CTRL-Break, and so on just result in a ? being displayed.

CTL-D (EOF on input) works for me? Or maybe the version I have (it was a
binary only that came off the Shoppa disks, IIRC) is slightly different from
the one you have, and that only works in this version (which has a number of
extensions).

I don't think I ever found any other way to exit it. Although looking at the
code, it seems like probably the only way is to generate a 'quit with core
dump' interrupt - I forget what character that is in standard V6.

	Noel

[TUHS] v6 debugging

[Will Senn]

On 1/23/16 12:03 PM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > I have cdb .. How do I exit it. %, CTRL-C, CTRL-D, CTRL-Z, Break,
>      > CTRL-Break, and so on just result in a ? being displayed.
>
> CTL-D (EOF on input) works for me? Or maybe the version I have (it was a
> binary only that came off the Shoppa disks, IIRC) is slightly different from
> the one you have, and that only works in this version (which has a number of
> extensions).
>
> I don't think I ever found any other way to exit it. Although looking at the
> code, it seems like probably the only way is to generate a 'quit with core
> dump' interrupt - I forget what character that is in standard V6.
>
> 	Noel
You are correct, CTL-D works. I must have typed it after I typed another 
key or something.

Thanks,

Will

[TUHS] v6 debugging

[Noel Chiappa]

    > From: Will Senn

    > How did folks debug assembly routines in Unix v6, back in the day?

There are three different questions here, although you may not realize it:

 - How did folks debug assembly routines in user programs in Unix v6
 - How did folks debug assembly routines in the kernel in Unix v6
 - How did folks debug assembly routines in PDP-11 standalone code created
   with Unix v6

I did all three, and I used different methods for each.

For user code, there was no source-level debugger, so debugging C programs
and debugging code written in assembler were the same thing. I used 'adb'
(which is, stricly speaking, slightly post-V6 - our system at MIT was
actually sort of an early PWB clone), but V6 itself provides 'db' (and also,
IIRC, 'cdb'); all three are very similar.

For standalone code (in my case, a packet switch that ran on PDP-11's), I
used a version of DDT that was linked in with the rest of the code. The
original version was one in MACRO-11 which I inherited from Jim Mathis at
SRI, but I eventually re-wrote it in portable C, and it was used on the 68K,
uVax and 29K.

For kernel assembler code... I can't remember what I did! Although I wrote a
fair amount of it (I modified m45.s very extensively, to work with the Able
ENABLE card), so I must have done _something_, but I have no idea what. In
theory I could have linked DDT in with the kernel, but I don't think I ever
did so?

Recently I was debugging some kernel code (the splice() system call we were
discussing here), and I debugged it using... printf()'s! It was written in C,
but I don't really differentiate between debugging C code, and assembler.


    > 2. No map file created by ld.

LD normally includes a symbol table in the output file, which 'nm' can dump.

    > 3. No debugger that I can find.

See above.

    > My workarounds include using OD to view the generated machine code

Use db/cdb/adb if you want to look at compiled code. Also, for 'cc', use the
-S flag.

	Noel

[TUHS] v6 debugging

[Will Senn]

On 1/23/16 11:18 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > How did folks debug assembly routines in Unix v6, back in the day?
>
> There are three different questions here, although you may not realize it:
>
>   - How did folks debug assembly routines in user programs in Unix v6
>   - How did folks debug assembly routines in the kernel in Unix v6
>   - How did folks debug assembly routines in PDP-11 standalone code created
>     with Unix v6
>
> I did all three, and I used different methods for each.
>
> For user code, there was no source-level debugger, so debugging C programs
> and debugging code written in assembler were the same thing. I used 'adb'
> (which is, stricly speaking, slightly post-V6 - our system at MIT was
> actually sort of an early PWB clone), but V6 itself provides 'db' (and also,
> IIRC, 'cdb'); all three are very similar.
>
> For standalone code (in my case, a packet switch that ran on PDP-11's), I
> used a version of DDT that was linked in with the rest of the code. The
> original version was one in MACRO-11 which I inherited from Jim Mathis at
> SRI, but I eventually re-wrote it in portable C, and it was used on the 68K,
> uVax and 29K.
>
> For kernel assembler code... I can't remember what I did! Although I wrote a
> fair amount of it (I modified m45.s very extensively, to work with the Able
> ENABLE card), so I must have done _something_, but I have no idea what. In
> theory I could have linked DDT in with the kernel, but I don't think I ever
> did so?
>
> Recently I was debugging some kernel code (the splice() system call we were
> discussing here), and I debugged it using... printf()'s! It was written in C,
> but I don't really differentiate between debugging C code, and assembler.
>
>
>      > 2. No map file created by ld.
>
> LD normally includes a symbol table in the output file, which 'nm' can dump.
>
>      > 3. No debugger that I can find.
>
> See above.
>
>      > My workarounds include using OD to view the generated machine code
>
> Use db/cdb/adb if you want to look at compiled code. Also, for 'cc', use the
> -S flag.
>
> 	Noel
I have cdb, it works. How do I exit it. %, CTRL-C, CTRL-D, CTRL-Z, 
Break, CTRL-Break, and so on just result in a ? being displayed. I 
checked the man page, no joy. It is possible to use %r to run the 
program at which point it exits, but I'm hoping there's a magic key 
combination...

db works too and it's exit is simply %.

Thanks,

Will

[TUHS] v6 debugging

[Will Senn]

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?

I realize that most folks didn't do assembly, but some did and I'm 
curious what their approach might have been.

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.
2. No map file created by ld.
3. No debugger that I can find.
4. This is not a missing feature, but it deserves inclusion in the list, 
the command as has possibly the most terse error messages I have ever 
seen - B 12? Really? Thankfully, the awesome man command comes to the 
rescue with the list of error codes.

My workarounds include using OD to view the generated machine code and 
adding mesg calls.

Thoughts?

Will

[TUHS] v6 debugging

[Brantley Coile]

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

I had a pdp-11/73 on which I ran 7th Edition. I debugged with print’s out the console. Usually I had a subroutine that would dump the registers including the PC, so I knew where it was. I used adb to get the absolute addresses. 

The ’73 also had a very simple debugger, ODT, built into the microcode. I never used it much, preferring to use printf in the C code and puts, puthex and snap in the assembler code.

I still use this technique working with our Plan 9 system today. 

Brantley

> On 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?
> 
> I realize that most folks didn't do assembly, but some did and I'm curious what their approach might have been.
> 
> 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.
> 2. No map file created by ld.
> 3. No debugger that I can find.
> 4. This is not a missing feature, but it deserves inclusion in the list, the command as has possibly the most terse error messages I have ever seen - B 12? Really? Thankfully, the awesome man command comes to the rescue with the list of error codes.
> 
> My workarounds include using OD to view the generated machine code and adding mesg calls.
> 
> Thoughts?
> 
> Will

[TUHS] v6 debugging

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

[TUHS] v6 debugging

[Clem Cole]

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

On Sat, Jan 23, 2016 at 12:30 PM, Clem Cole <clemc at ccc.com> wrote:

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

​Just read Noel's message -- sounds like the ddt came from Stanford and
MIT.   I don't remember the assembler version of it, but we definitely had
a C version for the 11 before V7.

I also had forgotten about db and cdb  - I could not tell you when they
appeared in the source stream without poking at Warren's archives.

BTW: I was thinking that the ddt came from the CU folks because they were
the folks that first got the DEC FTN to run on UNIX.  Since they did not
have access to  PDP-10 to run the BLISS compiler, the simulated it.   They
wrote a number of tools for the 11 and 10 in that project what were much
like the DEC tools from the PDP-10.


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