The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] SDB debugger
@ 2020-05-01 20:48 Paul Ruizendaal
  2020-05-01 21:57 ` Clem Cole
                   ` (3 more replies)
  0 siblings, 4 replies; 31+ messages in thread
From: Paul Ruizendaal @ 2020-05-01 20:48 UTC (permalink / raw)
  To: TUHS main list

Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers.

My current understanding is as follows:

- On 6th edition the debugger was ‘cdb’

- On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’

- In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements. 

- The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79.

- In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition.


Two questions:

(1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown?

(2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?




^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-01 20:48 [TUHS] SDB debugger Paul Ruizendaal
@ 2020-05-01 21:57 ` Clem Cole
  2020-05-02  9:10   ` Paul Ruizendaal
  2020-05-01 23:05 ` Jeremy C. Reed
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 31+ messages in thread
From: Clem Cole @ 2020-05-01 21:57 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]

On Fri, May 1, 2020 at 4:49 PM Paul Ruizendaal <pnr@planet.nl> wrote:

> Reading some more stuff about the road from 7th Edition to 8th Edition,
> this time about debuggers.
>
> My current understanding is as follows:
>
> - On 6th edition the debugger was ‘cdb’
>
One of the early USENIX tapes has a copy of ddt, which used the DEC DDT
syntax from the PDP-10 and PDP-11s.  I don't remember who created it.
Might have been Harvard or Cooper-Union.  I'm not sure I ever bothered to
learn cdb, as we had ddt at CMU.  What I don't remember is if it ran on
Fifth Edition.



> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>
Mumble -- IIRC adb was an attempt at being common between the PDP-11 and
the Interdata.   Heavy use of the pre-processor.  Typedefs did not get
exist.   Steve Johnson should chime in here.  I thought it was a new code
base.

Again, IIRC ddt did not just recompile on V7 and I needed something fast,
as I was trying to write what would become a 68000 backend for the C
compiler, so I just learned adb and never looked back until dbx.



>
> - In 32V a new debugger appears, ‘sdb’.

I thought adb was still in 32V also, adb was definitely in the BSD 4.x
codebase.



> Its code seems a derivative from ‘adb’, but the command language is
> substantially reworked and it uses a modified variant of the a.out linker
> format - in essence the beginnings of ‘stabs’. Of course the compiler,
> assembler, linker and related tools all emit/recognize these new symbol
> table elements.
>
> - The July 78 file note by London/Reiser does not mention a reworked
> debugger at all; the 32V tape that is on TUHS has ’sdb' files that are
> dated Feb/Mar 1979. This stuff must have been developed between July 78 and
> March 79.
>
> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79
> respectively) the stabs format is more developed. For SysIII it is ‘VAX
> only’. With these roots, it is not surprising that it is also in 8th
> Edition.
>
Don't forget Mark Linton's thesis, dbx  (which today has become gdb).  I
thought that was part of the original 4.1 (FastVax) tape; as part of the
new compilers from Susan Graham's students.   It certainly was part of
4.1c/4,2 as he had left for Stanford by then. [Note to Warren, we should
put 4.1 in the browsing tree.  The kernel is different enough from 4.0 and
does have new utilities, although it was not nearly as different as 4.1c.
The reality is until 4.2BSD came out with the networking support, most
Vaxen running BSD were 4.1 not 4.0 based.

FWIW: Does anyone know if dbx ended up 8 or 9th - Norman/Rob?

I also thought it was someone in Graham's team that had added support for
long identifiers.   Mary Ann did you remember/can you think of who that
might have been? But after that work was completed, the updated UCB
compilers went back to MH at some point, what changed were folded in I do
not know.

And of course, Steve started working on his new generation of compilers at
USG (PCC2), which would land in the System V stream.




>
>
> Two questions:
>
> (1) According to Wikipedia the original author of the stabs format is
> unknown. It also says that the original author of ‘sdb’ is unknown. Is that
> correct, is the author really unknown?
>
I don't remember, but it is possible this was UCB work that went back to
Bell.

BTW: wnj started out as a Graham student.  His fingers were on a number of
things (I think such as the Pascal subsystem in 1 and 2 BSD).  It is
possible he did something like the long identifiers, I just don't remember,
when they went into the system or who did it.  I thought that was with the
Vax, as the compilers were pressed for code (address) space on the 16-bit
systems.


>
> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16
> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem
> to me that the simple stabs format of 32V would have lent itself to being
> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool
> chain and debugger?
>
I don't know who would have done the work, other than someone like Bostic
(and he would have only done that if he needed it).   When did the 2.xBSD
line pick up the long identifiers?   Keith must have had something as the
Vax code started to assume them pretty soon after the feature was there.
FWIW: until the Linton's source debugger, the debugger I remember that most
of us used at UCB had been adb, not sdb.

The truth is that once the Vaxen showed up at UCB, most of the
grad-students like Mary Ann or myself all had accounts on those systems,
and things like the Cory Hall 70 were mostly undergrad machines being used
for teaching.  So most of the new work was being done in the Vax.
Bostic got his start as an undergrad moving things back from the Vax to the
machine(s) in Cory and Math/Statistics (which were 11's).  But the machines
being used for new features were definitely the Vax, so all of Graham's
students in languages were doing compiler work (or Linton's debugger) was
all vax based.

[-- Attachment #2: Type: text/html, Size: 8352 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-01 20:48 [TUHS] SDB debugger Paul Ruizendaal
  2020-05-01 21:57 ` Clem Cole
@ 2020-05-01 23:05 ` Jeremy C. Reed
  2020-05-02  0:49 ` Noel Hunt
  2020-05-12  4:15 ` Dave Horsfall
  3 siblings, 0 replies; 31+ messages in thread
From: Jeremy C. Reed @ 2020-05-01 23:05 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

> unknown. It also says that the original author of ?sdb? is unknown. Is 
> that correct, is the author really unknown?

Howard Katseff
See 3BSD: usr/doc/sdb/sdbrp.n
and
https://www.usenix.org/legacy/publications/library/proceedings/cinci93/full_papers/katseff.txt

I had also done some interview with him.  My Book (wip) says:

Katseff, who had already graduated from Berkeley in August 1978,
was working at Bell Labs in Holmdel
in the group developing 32/V. He started working on
sdb, a symbolic debugger for C language programs. It was used
for debugging core images from aborted programs. It could report
which original source code line caused the error, allowed
access to variables, define breakpoints, calling procedures,
and could single step on a line by line basis.
(Haley and Joy had provided constructive criticism during the sdb
development.)
% cite: archives/1970s/3bsd/usr/doc/sdb/sdbrp.n
% NOTE: Katseff didn't remember if that is for doc or code
This debugger was transferred to Berkeley along with the rest of
the 32/V operating system.\cite{katseff1}


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-01 20:48 [TUHS] SDB debugger Paul Ruizendaal
  2020-05-01 21:57 ` Clem Cole
  2020-05-01 23:05 ` Jeremy C. Reed
@ 2020-05-02  0:49 ` Noel Hunt
  2020-05-02  1:22   ` Rob Pike
  2020-05-02 20:16   ` Paul Ruizendaal
  2020-05-12  4:15 ` Dave Horsfall
  3 siblings, 2 replies; 31+ messages in thread
From: Noel Hunt @ 2020-05-02  0:49 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

When it comes to Eight Edition, please don't forget Tom Cargill's
'pi'. There was also a version I believe that was used as the
debugger for programs on the Blit/Jerq; it seems to be known as
'4pi' in the source.


On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:

> Reading some more stuff about the road from 7th Edition to 8th Edition,
> this time about debuggers.
>
> My current understanding is as follows:
>
> - On 6th edition the debugger was ‘cdb’
>
> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>
> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from
> ‘adb’, but the command language is substantially reworked and it uses a
> modified variant of the a.out linker format - in essence the beginnings of
> ‘stabs’. Of course the compiler, assembler, linker and related tools all
> emit/recognize these new symbol table elements.
>
> - The July 78 file note by London/Reiser does not mention a reworked
> debugger at all; the 32V tape that is on TUHS has ’sdb' files that are
> dated Feb/Mar 1979. This stuff must have been developed between July 78 and
> March 79.
>
> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79
> respectively) the stabs format is more developed. For SysIII it is ‘VAX
> only’. With these roots, it is not surprising that it is also in 8th
> Edition.
>
>
> Two questions:
>
> (1) According to Wikipedia the original author of the stabs format is
> unknown. It also says that the original author of ‘sdb’ is unknown. Is that
> correct, is the author really unknown?
>
> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16
> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem
> to me that the simple stabs format of 32V would have lent itself to being
> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool
> chain and debugger?
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2659 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02  0:49 ` Noel Hunt
@ 2020-05-02  1:22   ` Rob Pike
  2020-05-02  3:49     ` Noel Hunt
  2020-05-02 20:16   ` Paul Ruizendaal
  1 sibling, 1 reply; 31+ messages in thread
From: Rob Pike @ 2020-05-02  1:22 UTC (permalink / raw)
  To: Noel Hunt; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]

I don't remember dbx appearing in our lab, but that doesn't mean it wasn't
there.

I did quite a bit of work on adb, renamed db, mostly finishing things up
and fixing a lot of bugs, to make it actually work in Plan 9. I had several
conversations with Steve Bourne about it to understand why it seemed
broken, and how to fix it. Once fixed, It could do some remarkable stuff
but nobody but me seemed to care because it was lower level than
cdb/sdb/gdb. I liked it because, once those bugs were fixed, it got the
right answer, something gdb never did back then. The [scg]db of yesteryear
was far too unreliable and crashy for me. After it  dumped core for the nth
time on top of the core I was debugging, I gave up on it. But I was never a
debugger-first programmer. None of us in the lab were, and that's probably
why the debugging setup in Unix is to this day so weak compared to what
other systems provide.

The sdb/gdb line also had a peculiar property of not answering the question
you were asking, although I don't remember the details. It was more
interested in the symbols than the code, and that could get in the way. The
failure of the compiler to give good symbols didn't help. And now we have
DWARF, for which my only comment is: oof, the sound one makes catching a
dropped bag of concrete mix.

One debugger that we used a lot, although more as a scripting language for
things like tracing system calls and checking for malloc leaks than as an
interactive tool, was Phil Winterbottom's Acid. It has a crazy language but
once you licked it (I think the only three who did were Phil, me, and Russ
Cox) it was very powerful. Acme had some front-end code for it that made it
great for displaying multithreaded program stacks.

Pi was cool, but that was earlier and tied to the Jerq/Blit and C++.

-rob


On Sat, May 2, 2020 at 10:50 AM Noel Hunt <noel.hunt@gmail.com> wrote:

> When it comes to Eight Edition, please don't forget Tom Cargill's
> 'pi'. There was also a version I believe that was used as the
> debugger for programs on the Blit/Jerq; it seems to be known as
> '4pi' in the source.
>
>
> On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:
>
>> Reading some more stuff about the road from 7th Edition to 8th Edition,
>> this time about debuggers.
>>
>> My current understanding is as follows:
>>
>> - On 6th edition the debugger was ‘cdb’
>>
>> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>>
>> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from
>> ‘adb’, but the command language is substantially reworked and it uses a
>> modified variant of the a.out linker format - in essence the beginnings of
>> ‘stabs’. Of course the compiler, assembler, linker and related tools all
>> emit/recognize these new symbol table elements.
>>
>> - The July 78 file note by London/Reiser does not mention a reworked
>> debugger at all; the 32V tape that is on TUHS has ’sdb' files that are
>> dated Feb/Mar 1979. This stuff must have been developed between July 78 and
>> March 79.
>>
>> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79
>> respectively) the stabs format is more developed. For SysIII it is ‘VAX
>> only’. With these roots, it is not surprising that it is also in 8th
>> Edition.
>>
>>
>> Two questions:
>>
>> (1) According to Wikipedia the original author of the stabs format is
>> unknown. It also says that the original author of ‘sdb’ is unknown. Is that
>> correct, is the author really unknown?
>>
>> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16
>> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem
>> to me that the simple stabs format of 32V would have lent itself to being
>> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool
>> chain and debugger?
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 5000 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02  1:22   ` Rob Pike
@ 2020-05-02  3:49     ` Noel Hunt
  0 siblings, 0 replies; 31+ messages in thread
From: Noel Hunt @ 2020-05-02  3:49 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 4986 bytes --]

> Pi was cool, but that was earlier and tied to the Jerq/Blit and C++.

I believe Dave Kapilow kept up development of pi at Bell,
long after Tom Cargill had left research. There is a CDROM
of pi as of about 2002, with versions compilable for various
architectures, but the terminal part, which was actually 'pads',
originally Blit graphics, was replaced with Openlook. It isn't
hard to get pads working with the Plan graphics model.

The problem with that distribution is that it is still all
stabs-based, and although dwarf is a nightmare, being able to
read dwarf symbol tables in pi would be a pleasing step forward.
Dealing with dwarf is a struggle, but Russ Cox and Rob Pike have
written perhaps the only sane code in the world to deal with the
complexities in a nice way. One is advised to avoid 'libdwarf'.

On Sat, May 2, 2020 at 11:22 AM Rob Pike <robpike@gmail.com> wrote:

> I don't remember dbx appearing in our lab, but that doesn't mean it wasn't
> there.
>
> I did quite a bit of work on adb, renamed db, mostly finishing things up
> and fixing a lot of bugs, to make it actually work in Plan 9. I had several
> conversations with Steve Bourne about it to understand why it seemed
> broken, and how to fix it. Once fixed, It could do some remarkable stuff
> but nobody but me seemed to care because it was lower level than
> cdb/sdb/gdb. I liked it because, once those bugs were fixed, it got the
> right answer, something gdb never did back then. The [scg]db of yesteryear
> was far too unreliable and crashy for me. After it  dumped core for the nth
> time on top of the core I was debugging, I gave up on it. But I was never a
> debugger-first programmer. None of us in the lab were, and that's probably
> why the debugging setup in Unix is to this day so weak compared to what
> other systems provide.
>
> The sdb/gdb line also had a peculiar property of not answering the
> question you were asking, although I don't remember the details. It was
> more interested in the symbols than the code, and that could get in the
> way. The failure of the compiler to give good symbols didn't help. And now
> we have DWARF, for which my only comment is: oof, the sound one makes
> catching a dropped bag of concrete mix.
>
> One debugger that we used a lot, although more as a scripting language for
> things like tracing system calls and checking for malloc leaks than as an
> interactive tool, was Phil Winterbottom's Acid. It has a crazy language but
> once you licked it (I think the only three who did were Phil, me, and Russ
> Cox) it was very powerful. Acme had some front-end code for it that made it
> great for displaying multithreaded program stacks.
>
> Pi was cool, but that was earlier and tied to the Jerq/Blit and C++.
>
> -rob
>
>
> On Sat, May 2, 2020 at 10:50 AM Noel Hunt <noel.hunt@gmail.com> wrote:
>
>> When it comes to Eight Edition, please don't forget Tom Cargill's
>> 'pi'. There was also a version I believe that was used as the
>> debugger for programs on the Blit/Jerq; it seems to be known as
>> '4pi' in the source.
>>
>>
>> On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:
>>
>>> Reading some more stuff about the road from 7th Edition to 8th Edition,
>>> this time about debuggers.
>>>
>>> My current understanding is as follows:
>>>
>>> - On 6th edition the debugger was ‘cdb’
>>>
>>> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
>>>
>>> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from
>>> ‘adb’, but the command language is substantially reworked and it uses a
>>> modified variant of the a.out linker format - in essence the beginnings of
>>> ‘stabs’. Of course the compiler, assembler, linker and related tools all
>>> emit/recognize these new symbol table elements.
>>>
>>> - The July 78 file note by London/Reiser does not mention a reworked
>>> debugger at all; the 32V tape that is on TUHS has ’sdb' files that are
>>> dated Feb/Mar 1979. This stuff must have been developed between July 78 and
>>> March 79.
>>>
>>> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79
>>> respectively) the stabs format is more developed. For SysIII it is ‘VAX
>>> only’. With these roots, it is not surprising that it is also in 8th
>>> Edition.
>>>
>>>
>>> Two questions:
>>>
>>> (1) According to Wikipedia the original author of the stabs format is
>>> unknown. It also says that the original author of ‘sdb’ is unknown. Is that
>>> correct, is the author really unknown?
>>>
>>> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16
>>> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem
>>> to me that the simple stabs format of 32V would have lent itself to being
>>> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool
>>> chain and debugger?
>>>
>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 7840 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-01 21:57 ` Clem Cole
@ 2020-05-02  9:10   ` Paul Ruizendaal
  2020-05-02 16:04     ` Clem Cole
  0 siblings, 1 reply; 31+ messages in thread
From: Paul Ruizendaal @ 2020-05-02  9:10 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]


> On May 1, 2020, at 11:57 PM, Clem Cole <clemc@ccc.com> wrote:

> [Note to Warren, we should put 4.1 in the browsing tree.  The kernel is different enough from 4.0 and does have new utilities, although it was not nearly as different as 4.1c.  The reality is until 4.2BSD came out with the networking support, most Vaxen running BSD were 4.1 not 4.0 based.

It is already there! The entry named "BBN's TCP/IP Code for the VAX” is 4.1BSD with the BBN TCP stack added. The changes to the kernel are just one or two dozen lines (all in sys2.c and main.c) bracketed in #ifdef BBNNET blocks. The actual network stack is in a separate build directory.

Maybe the entry should be renamed “4.1BSD with TCP/IP” to make this more clear.



[-- Attachment #2: Type: text/html, Size: 1411 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02  9:10   ` Paul Ruizendaal
@ 2020-05-02 16:04     ` Clem Cole
  0 siblings, 0 replies; 31+ messages in thread
From: Clem Cole @ 2020-05-02 16:04 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

Paul - you are correct that its got a lot of it there and in particular the
kernel (which is good).  But the /usr directory (and thus /usr/src) is
missing.  It's not a completely distribution, it's the BBN 4.1 TCP
distribution which was a subset.

As I said, 4.0 and 4.1 were similar, but different.

The trick is find a complete 4.1 distribution tape.

On Sat, May 2, 2020 at 5:10 AM Paul Ruizendaal <pnr@planet.nl> wrote:

>
> On May 1, 2020, at 11:57 PM, Clem Cole <clemc@ccc.com> wrote:
>
>
> [Note to Warren, we should put 4.1 in the browsing tree.  The kernel is
> different enough from 4.0 and does have new utilities, although it was not
> nearly as different as 4.1c.  The reality is until 4.2BSD came out with the
> networking support, most Vaxen running BSD were 4.1 not 4.0 based.
>
>
> It is already there! The entry named "BBN's TCP/IP Code for the VAX” is
> 4.1BSD with the BBN TCP stack added. The changes to the kernel are just one
> or two dozen lines (all in sys2.c and main.c) bracketed in #ifdef BBNNET
> blocks. The actual network stack is in a separate build directory.
>
> Maybe the entry should be renamed “4.1BSD with TCP/IP” to make this more
> clear.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2266 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02  0:49 ` Noel Hunt
  2020-05-02  1:22   ` Rob Pike
@ 2020-05-02 20:16   ` Paul Ruizendaal
  2020-05-03  6:58     ` arnold
  2020-05-03 16:13     ` Clem Cole
  1 sibling, 2 replies; 31+ messages in thread
From: Paul Ruizendaal @ 2020-05-02 20:16 UTC (permalink / raw)
  To: TUHS main list

Thanks, all, for that input.

The ddt debugger appears to be a fork of 5th edition cdb. It survived in the Interdata 7/32 port:
https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/chicago
It appears to have originated from Bill Allen at the Naval Postgraduate School.


Some more reading appears to show a much more gradual development than I first thought. Working along Doug’s list:

- First there was db, which claims to be loosely based on DEC’s ODT in its man page. Written in assembler.

- Then there is cdb, a rewrite in C, as from 3rd edition. Judging from the man pages, in 3rd and 4th edition it is a mostly incomplete project.

- The first reasonably complete version of cdb appears in 5th edition. It only handles “normal” symbols (see below for “normal”). The ddt debugger forks from this version, presumably to fill in some missing features (e.g. access to non-C identifiers, single stepping, etc.; I have not done a full feature comparison).

- In 6th edition “pseudo” symbols are introduced: symbols starting with a tilde that provide names for auto and register variables. The cdb debugger is updated to allow references to local variables using a “procname:varname” syntax. The ddt debugger picked this up as well. It is a first step towards the stabs format.

I would assume that db and cdb are the work of dmr/ken.

- In 7th edition there is the new adb, by Steve Bourne. Main focus of adb appears to have been portability more than major new features. Again, I have not compared the feature sets of ddt and adb to see if there was an influence.

- In 32V the symbol format is changed: (i) the “tilde hack” is replaced by a new assembler pseudo op “.stabs”; (ii) this is then used to include more pseudo symbols, for line numbers, for file names, etc.; (iii) the symbol struct is extended with a field to hold the symbol's type. It is essentially stabs, but with 8 char names. A new source level debugger, sdb, allows source level debugging. Its command language is the first to feel like a gdb ancestor. Author Howard Katseff.

The dbx debugger appears to stand on the shoulders of sdb, and gdb on the shoulders of dbx.

In 8th edition there are 3 debuggers: adb, sdb and pi (for use with the Blit).



> On 2 May 2020, at 02:49, Noel Hunt <noel.hunt@gmail.com> wrote:
> 
> When it comes to Eight Edition, please don't forget Tom Cargill's
> 'pi'. There was also a version I believe that was used as the
> debugger for programs on the Blit/Jerq; it seems to be known as
> '4pi' in the source.
> 
> 
> On Sat, May 2, 2020 at 6:49 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers.
> 
> My current understanding is as follows:
> 
> - On 6th edition the debugger was ‘cdb’
> 
> - On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
> 
> - In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements. 
> 
> - The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79.
> 
> - In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition.
> 
> 
> Two questions:
> 
> (1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown?
> 
> (2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?
> 
> 
> 


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02 20:16   ` Paul Ruizendaal
@ 2020-05-03  6:58     ` arnold
  2020-05-03 16:13     ` Clem Cole
  1 sibling, 0 replies; 31+ messages in thread
From: arnold @ 2020-05-03  6:58 UTC (permalink / raw)
  To: tuhs, pnr

Paul Ruizendaal <pnr@planet.nl> wrote:

> The dbx debugger appears to stand on the shoulders of sdb,
> and gdb on the shoulders of dbx.

I think this is a fair statement with respect to command languages
and how they work, but probably not w.r.t. shared code bases (a guess,
but particularly in the case of gdb I bet that would have been
written from scratch.)

This only makes sense, too. The user base's first source level
debugger would have been sdb.  Modelling dbx after sdb (to whatever
extent) makes it easier for users to pick it up.

Similarly, I remember moving from dbx to gdb; it was straightforward,
but also a big improvement in terms of the command line.

My two cents :-)

Arnold

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02 20:16   ` Paul Ruizendaal
  2020-05-03  6:58     ` arnold
@ 2020-05-03 16:13     ` Clem Cole
  2020-05-03 16:53       ` Henry Bent
                         ` (3 more replies)
  1 sibling, 4 replies; 31+ messages in thread
From: Clem Cole @ 2020-05-03 16:13 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

On Sat, May 2, 2020 at 4:16 PM Paul Ruizendaal <pnr@planet.nl> wrote:

> The dbx debugger appears to stand on the shoulders of sdb, and gdb on the
> shoulders of dbx.
>
Mumble ...   It's true rms started with dbx and peed on it in their
usually way - similar to the Gosling EMACS to GnuEMACS story.

But  Mark wrote DBX from scratch, although I would be surprised if looked
at how adb and sdb handled the symbol table and could have lifted that code
from their.   If I remember discussions with him about it, his interface
model was really more VMS debugger more than sdb.   As I said, I really
don't remember anyone at UCB in those days using sdb.

At the time, there was a huge push (mostly from the Stanford crew) to make
VMS the Arpa standard system replacing the PDP-10, TOPS, Tenex, ITS, et
al.  Besides the performance argument (hence the 4.1 FASTVAX work), one of
the arguments from the pro-VMS side was the language toolchain, including
comments that UNIX did not have a debugger in the same vein as VMS (and
also that the Fortran system was considered pretty weak).

When he was still at UCB, Mark had tried to make sure dbx worked with both
C and Fortran (i.e. at the beginning of the project I did some testing for
him because I was working on a large array processor in the CAD group, that
needed to compile EE CAD suite which at that point was heavily dominated by
Fortran codes).  The whole BSD UNIX Fortran was not great and I know when
Masscomp built their debugger, they started with dbx and had to gut the
multiple language support (thus rewriting much of the Fortran & Pascal
support); but the person that did it, had been part of DEC's TLG team
previously and had a direct knowledge of how the DEC debugger actually
handled multiple languages.    BTW the time, I personally did not really
care, as long as C support worked.

Paul W -- do you remember if DEC TLG did a version of dbx for Ultrix
(Leslie might remember)?  FWIW: I know that DEC had a number of different
debugger projects so on the UNIX side over the years, and I really don't
remember what was done for the VAX, as I was not there at the time.  By
MIPS/Alpha in the mid-late 90's there was a whole new debugger stream that
had been developed at part of GEM, but there was another one that came from
MIPs too which was based on dbx.

Clem

[-- Attachment #2: Type: text/html, Size: 3751 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:13     ` Clem Cole
@ 2020-05-03 16:53       ` Henry Bent
  2020-05-03 17:06         ` Henry Bent
  2020-05-03 17:13       ` Henry Bent
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 31+ messages in thread
From: Henry Bent @ 2020-05-03 16:53 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Sun, 3 May 2020 at 12:14, Clem Cole <clemc@ccc.com> wrote:

>
> Paul W -- do you remember if DEC TLG did a version of dbx for Ultrix
> (Leslie might remember)?  FWIW: I know that DEC had a number of different
> debugger projects so on the UNIX side over the years, and I really don't
> remember what was done for the VAX, as I was not there at the time.  By
> MIPS/Alpha in the mid-late 90's there was a whole new debugger stream that
> had been developed at part of GEM, but there was another one that came from
> MIPs too which was based on dbx.
>

Perhaps unsurprisingly, as Ultrix 1 was basically just 4.2BSD with some
tweaks/addons, dbx has been there since the beginning as /usr/ucb/dbx.  The
binary in 1.1 has SCCS strings mostly dating it to '83 and the 2.0 source
tree has dates that are mostly December '84.

-Henry

[-- Attachment #2: Type: text/html, Size: 1294 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:53       ` Henry Bent
@ 2020-05-03 17:06         ` Henry Bent
  0 siblings, 0 replies; 31+ messages in thread
From: Henry Bent @ 2020-05-03 17:06 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Sun, 3 May 2020 at 12:53, Henry Bent <henry.r.bent@gmail.com> wrote:

> On Sun, 3 May 2020 at 12:14, Clem Cole <clemc@ccc.com> wrote:
>
>>
>> Paul W -- do you remember if DEC TLG did a version of dbx for Ultrix
>> (Leslie might remember)?  FWIW: I know that DEC had a number of different
>> debugger projects so on the UNIX side over the years, and I really don't
>> remember what was done for the VAX, as I was not there at the time.  By
>> MIPS/Alpha in the mid-late 90's there was a whole new debugger stream that
>> had been developed at part of GEM, but there was another one that came from
>> MIPs too which was based on dbx.
>>
>
> Perhaps unsurprisingly, as Ultrix 1 was basically just 4.2BSD with some
> tweaks/addons, dbx has been there since the beginning as /usr/ucb/dbx.  The
> binary in 1.1 has SCCS strings mostly dating it to '83 and the 2.0 source
> tree has dates that are mostly December '84.
>

Ultrix-32m 1.0 also has dbx, with dates no later than August '83.  These
dates mostly correspond to the 4.2 source tree on TUHS (
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/ucb/dbx ) but
not exactly - the 4.2 tree has a newer object.c, implying that DEC was
getting early copies of 4.2.  The later fixes in Ultrix 1.1 also imply that
DEC was getting regular updates from UCB.

-Henry

[-- Attachment #2: Type: text/html, Size: 2138 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:13     ` Clem Cole
  2020-05-03 16:53       ` Henry Bent
@ 2020-05-03 17:13       ` Henry Bent
  2020-05-03 20:26         ` Clem Cole
  2020-05-03 17:35       ` [TUHS] " Paul Winalski
  2020-05-03 21:27       ` Paul Ruizendaal
  3 siblings, 1 reply; 31+ messages in thread
From: Henry Bent @ 2020-05-03 17:13 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Sun, 3 May 2020 at 12:14, Clem Cole <clemc@ccc.com> wrote:

>
> By MIPS/Alpha in the mid-late 90's there was a whole new debugger stream
> that had been developed at part of GEM, but there was another one that came
> from MIPs too which was based on dbx.
>

This raises a question I've always had - what was the relationship between
DEC's compilers on MIPS/Alpha and the work the MIPS folks did?  Early
versions of OSF/1 on both platforms have tools that are very, very similar
to the MIPS compiler suite - ugen, uopt, two-pass assembler, etc. - and
I've always been curious what the heritage was there.

-Henry

[-- Attachment #2: Type: text/html, Size: 1051 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:13     ` Clem Cole
  2020-05-03 16:53       ` Henry Bent
  2020-05-03 17:13       ` Henry Bent
@ 2020-05-03 17:35       ` Paul Winalski
  2020-05-03 21:27       ` Paul Ruizendaal
  3 siblings, 0 replies; 31+ messages in thread
From: Paul Winalski @ 2020-05-03 17:35 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Paul Ruizendaal

On 5/3/20, Clem Cole <clemc@ccc.com> wrote:
>
> Paul W -- do you remember if DEC TLG did a version of dbx for Ultrix
> (Leslie might remember)?  FWIW: I know that DEC had a number of different
> debugger projects so on the UNIX side over the years, and I really don't
> remember what was done for the VAX, as I was not there at the time.  By
> MIPS/Alpha in the mid-late 90's there was a whole new debugger stream that
> had been developed at part of GEM, but there was another one that came from
> MIPs too which was based on dbx.

DEC's Technical Languages & Environments (TLE) group was responsible
for compilers for BLISS, Fortran, Pascal, PL/I, and Ada, on the
languages side, and the Language-Sensitive Editor (LSE) and debugger
on the software tools side.  All for VMS on the VAX and RSX-11, RT-11,
and RSTS on the PDP-11.  When VAX Ultrix came along, TLE ported the
VMS Fortran compiler and runtime to run on Ultrix.  It was a rush-rush
project and it was decided that there wasn't enough time to modify the
Fortran compiler to produce a.out object files or as assembler files
directly.  Instead Caroline Davidson and I modified the VMS linker to
run on Ultrix and to accept a.out and .a archive files as well as VMS
object files, and to produce a.out executables.  This linker was
called lk.  Part of this project was code to translate the debug
information in VMS object files to a.out stabs.  That work was done by
two members of the Ultrix development team (I don't recall their
names).

So VAX Fortran for Ultrix used the off-the-shelf Ultrix debugger.
DEC's MIPS and Alpha Unix offerings used COFF as the object file and
executable format, and the GEM common back end emitted COFF-style
stabs for those platforms.  I was the project leader for the group
that developed and maintained the object file emission code in the GEM
compiler back end, but Ron Brender, who did a LOT of research on
debugging highly-optimized code and parallel programs, maintained the
GEM code that generated debug information.  I know that all of Ron's
work ended up in the VMS debugger.  I don't know how much of it went
into the Unix side of things.

I wasn't paying too much attention at the time, but I believe TLE also
did its own debugger for the Alpha Unix platform.  John Bishop can
tell you more about that.  When Microsoft sold Visual Fortran to DEC,
TLE took over the toolchain and interactive development environment
and released it as Digital Visual Fortran (DVF).  When Compaq sold the
Alpha technology to Intel, DVF went with it and became Intel Visual
Fortran, although the Intel compiler back end was chosen and GEM was
abandoned.  An Intel debugger, idb, was offered on Linux, although not
on Unix IIRC.  It was based on the DEC Alpha debugger technology.
This was later replaced by a debugger based on gdb.

-Paul W.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 17:13       ` Henry Bent
@ 2020-05-03 20:26         ` Clem Cole
  2020-05-05  0:22           ` [TUHS] DEC Compilers (was: " Win Treese
  0 siblings, 1 reply; 31+ messages in thread
From: Clem Cole @ 2020-05-03 20:26 UTC (permalink / raw)
  To: Henry Bent; +Cc: TUHS main list, Paul Ruizendaal

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

On Sun, May 3, 2020 at 1:13 PM Henry Bent <henry.r.bent@gmail.com> wrote:

> This raises a question I've always had - what was the relationship between
> DEC's compilers on MIPS/Alpha and the work the MIPS folks did?  Early
> versions of OSF/1 on both platforms have tools that are very, very similar
> to the MIPS compiler suite - ugen, uopt, two-pass assembler, etc. - and
> I've always been curious what the heritage was there.
>
I can answer that ;-)

You need to understand/remember that the first OS that ran on Alpha was a
port of the Ultrix/MIPS base.  We debugged the hardware with Ultrix (not
VMS).   The key is that DEC had full rights to all the MIPS tools.   So a
quick redo of the MIPS/3000 backend was made to emit Alpha since GEM was
not really ready yet and Ultrix was way more portable than VMS was.

There was a big fight about if Ultrix/Alpha should ship or not, which as we
know never happened as Tru64 was to be the new OS base (particularly since
DC had taken Mica to Microsoft which became NT etc..).  In practice, one of
the big problems was that Tru64 was OSF/1 really in name and command system
only.   The Tru64 team kept rewriting large kernel subsystems under the
rules of "this code is not 64-bit clean", or "it's immature, I need to
rewrite I can't understand it", "We need better SCSI support," "the TTY
driver sucks," *etc*. ...

The idea of 'perfection' was very high on people's minds.   As I have
always said, every one of those choices could be argued as the correct one
technically and in the small, but when you integrate against the whole,
Tru64 was 3 years late (and DEC had not revenue because other than a little
bit of business in system refresh, few people wanted to buy new Vaxen or
MIPS boxes -- they went to Sun).  So it was actually a bad idea.  They
should have shipped OSF/1-Alpha as is and then tweaked it to become Tru64
over time.  Or they could have shipped the early OSF/1 for Alpha and MIPS
together as a stepping stone - the later did actually Shipp under a special
license to a few research sites but was never productive.  I don't think
the former ever left the building.

Anyway back to compilers, Tru64 had a 'good enough' compiler based on the
MIPS code base to get us all going, but GEM's primary target was VMS since
one of the important features of GEM was the VAX->Alpha transpiler
technology.   VMS was still heavily written in VAX Assembler at the time.
Plus, It actually was a little hairy because GEM had a new C/C++
front-end.   So TLE's high order bit was VMS for the Alphas.   GEM for
Tru64 was about 18 months later.

This was also a mixed blessing -- one thing was GEM caught a huge number of
64-bit-ism (God Bless Judy Ward's error detection code).   Most large
ISV's were having big issues with 32-bit dirty code and in particular the
ILP32 assumption (all 64-bit UNIX's use the LP64 model).  At that point,
there were absolutely no tools in the market to help people move to the new
64-bit world.  So until the GEM compiler showed up, ISVs were pretty slow
in getting their code cleaned.  The funny part of all that work is that DEC
basically paid the big ISVs (read Oracle et al) to make their code work on
later generations of MIP, SUN, and INTEL*64.   I know of a number of ISV's
that discovered after the Tru64/Alpha port, their bug rate dropped and a
whole ton of bugs in the basic codebase had been eliminated.  As an aside,
to do this day, if I am given an old piece of C or C++ that I want to run
on a modern system (like I was a couple of weeks ago to read some old
tapes), I fire up my Alpha and feed the sources to Judy'd front-end and
listen very carefully to her warnings -- if the GEM Tru64 compiler can
accept it without warnings, I have never had a case where the code did not
'just work' when I recompiled for my Mac when I brought it back.

[-- Attachment #2: Type: text/html, Size: 5279 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:13     ` Clem Cole
                         ` (2 preceding siblings ...)
  2020-05-03 17:35       ` [TUHS] " Paul Winalski
@ 2020-05-03 21:27       ` Paul Ruizendaal
  3 siblings, 0 replies; 31+ messages in thread
From: Paul Ruizendaal @ 2020-05-03 21:27 UTC (permalink / raw)
  To: TUHS main list


> On 3 May 2020, at 18:13, Clem Cole <clemc@ccc.com> wrote:
> 
> On Sat, May 2, 2020 at 4:16 PM Paul Ruizendaal <pnr@planet.nl> wrote:
> The dbx debugger appears to stand on the shoulders of sdb, and gdb on the shoulders of dbx.
> Mumble ...   It's true rms started with dbx and peed on it in their usually way - similar to the Gosling EMACS to GnuEMACS story.

> But  Mark wrote DBX from scratch, although I would be surprised if looked at how adb and sdb handled the symbol table and could have lifted that code from their.   If I remember discussions with him about it, his interface model was really more VMS debugger more than sdb.   As I said, I really don't remember anyone at UCB in those days using sdb.

I meant that in the sense of Feynmann standing on the shoulders of Einstein, in turn standing on the shoulders of Newton. Not in the sense of swiping stuff.

Things seem to have evolved quite substantially in the 1979-1982 time frame. With 1979 SDB, a.out and its symbols evolve and gain (C based) type information. In 4BSD, late 1980, it evolves some more and gains long symbol names (i.e. >8 chars). SDB tracks this, but stays basically the same.

It would seem that one of the innovations in the first versions of DBX (surviving in 4.1c, end of 1982) was to make use of these long names to store much more detailed type information than the 16-bit field used for this in SDB.

SDB seems to have had a short life: in the V8 source on TUHS is a readme saying that it has been deprecated:

"sdb is deprecated these days.  what's here works, but needs a lot of cleanup.
c works reasonably well.  f77 works barely, especially in areas near
equivalence and common.  (f77 needs cleaning up just as badly.)”

All that seems to match your recollections.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] DEC Compilers (was: Re:  SDB debugger
  2020-05-03 20:26         ` Clem Cole
@ 2020-05-05  0:22           ` Win Treese
  2020-05-05 17:36             ` Paul Winalski
  2020-05-05 21:49             ` Henry Bent
  0 siblings, 2 replies; 31+ messages in thread
From: Win Treese @ 2020-05-05  0:22 UTC (permalink / raw)
  To: TUHS main list


> On May 3, 2020, at 4:26 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> Anyway back to compilers, Tru64 had a 'good enough' compiler based on the MIPS code base to get us all going, but GEM's primary target was VMS since one of the important features of GEM was the VAX->Alpha transpiler technology.   VMS was still heavily written in VAX Assembler at the time.  Plus, It actually was a little hairy because GEM had a new C/C++ front-end.   So TLE's high order bit was VMS for the Alphas.   GEM for Tru64 was about 18 months later. 

In the early days of Alpha, I was at DEC’s Cambridge Research Laboratory (directed then by Vic Vyssotsky, having retired from Bell Labs). The lab had various connections to Alpha projects, and we learned that there were (I think) 7 different C compilers running on the early port of Ultrix. That number, I think, did not include the port of gcc that DEC was funding outside the company.

Andy Payne, a recent hire at the lab, had been an intern in DEC’s semiconductor group, where he had worked on randomized testing for hardware verification. With all the compilers available, he decided to hack up a program to generate random small C programs with computable expected outputs. His program then compiled the random code with each compiler and tested the result. After finding a number of bugs this way, he got tired of submitting the bug reports, and changed his program to write and submit the bug reports automatically. 

This caused a little bit of consternation with some of the compiler teams at first.

Eventually, this led to some collaboration with the DEC languages and tools team, and Bill McKeeman published a paper that line of work in the Digital Technical Journal in 1998[1].

 - Win

[1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
  2020-05-05  0:22           ` [TUHS] DEC Compilers (was: " Win Treese
@ 2020-05-05 17:36             ` Paul Winalski
  2020-05-05 18:53               ` Dr Iain Maoileoin
  2020-05-05 21:59               ` Dan Cross
  2020-05-05 21:49             ` Henry Bent
  1 sibling, 2 replies; 31+ messages in thread
From: Paul Winalski @ 2020-05-05 17:36 UTC (permalink / raw)
  To: Win Treese; +Cc: TUHS main list

On 5/4/20, Win Treese <treese@acm.org> wrote:
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> semiconductor group, where he had worked on randomized testing for hardware
> verification. With all the compilers available, he decided to hack up a
> program to generate random small C programs with computable expected
> outputs. His program then compiled the random code with each compiler and
> tested the result. After finding a number of bugs this way, he got tired of
> submitting the bug reports, and changed his program to write and submit the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler teams at
> first.

I remember that very well.  IIRC it was called fuzz testing, and
indeed it was controversial, for the reasons Bill McKeeman discusses
in his paper. [1]  On the one hand, compiler developers said, "nobody
would ever write something like that--we can't waste our time on these
issues when there are real bugs waiting to be fixed."  On the other
hand, some of the bugs that fuzz testing turned up provoked reactions
such as, "OMG!  THAT caused the compiler to crash?"  I think the
turning point was when fixing one of the fuzz testing bugs also fixed
an obscure and hard-to-debug customer problem.  Intel's C and Fortran
compiler team has also used random testing technology.

> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf

-Paul W.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
  2020-05-05 17:36             ` Paul Winalski
@ 2020-05-05 18:53               ` Dr Iain Maoileoin
  2020-05-05 21:59               ` Dan Cross
  1 sibling, 0 replies; 31+ messages in thread
From: Dr Iain Maoileoin @ 2020-05-05 18:53 UTC (permalink / raw)
  To: Paul Winalski; +Cc: TUHS main list


> On 5 May 2020, at 18:36, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 5/4/20, Win Treese <treese@acm.org> wrote:
>> 
>> ….
>> This caused a little bit of consternation with some of the compiler teams at
>> first.
> 
> I remember that very well.  IIRC it was called fuzz testing, and
> ….
> compiler team has also used random testing technology.
> 
>> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
> 
> -Paul W.

Way back in the deep past - late 70s I think - The Computer Science Department at Strathclyde  Uni in Scotland had a contract to develop a test suite generator for the C compiler on the ICL perq computer.  I think the testing/development for that compiler was happening at Dalkeith in Scotland - but dont quote me.

Like the above we generated programs (e.g. mixing short, int, long signed and unsigned and doing all sort of ops on them).  The expected output was computed by the same C program running on a BSD unix vax and something else.  We had a few issues with the vax and the other system disagreeing on the arithmetic results, but generally we were confident the random C programs would reasonably test the system under test.  We did not get to see the results of the tests,  we developed the suite and handed it over to ICL.

Overall we were not impressed by the PERQ and on a trip to Rutherford Appleton Labs (RAL) one November there was a HUGE bonfire being prepared (for our Guy Falkes(sp) celebration).  The bonfire was generally comprised of the PERQ cardboard packing cases.  It just looked like they were planning to burn the PERQs themselves.  We agreed with the sentiment.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
  2020-05-05  0:22           ` [TUHS] DEC Compilers (was: " Win Treese
  2020-05-05 17:36             ` Paul Winalski
@ 2020-05-05 21:49             ` Henry Bent
  1 sibling, 0 replies; 31+ messages in thread
From: Henry Bent @ 2020-05-05 21:49 UTC (permalink / raw)
  To: Win Treese; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

On Mon, 4 May 2020 at 20:33, Win Treese <treese@acm.org> wrote:

>
> > On May 3, 2020, at 4:26 PM, Clem Cole <clemc@ccc.com> wrote:
> >
> > Anyway back to compilers, Tru64 had a 'good enough' compiler based on
> the MIPS code base to get us all going, but GEM's primary target was VMS
> since one of the important features of GEM was the VAX->Alpha transpiler
> technology.   VMS was still heavily written in VAX Assembler at the time.
> Plus, It actually was a little hairy because GEM had a new C/C++
> front-end.   So TLE's high order bit was VMS for the Alphas.   GEM for
> Tru64 was about 18 months later.
>
> In the early days of Alpha, I was at DEC’s Cambridge Research Laboratory
> (directed then by Vic Vyssotsky, having retired from Bell Labs). The lab
> had various connections to Alpha projects, and we learned that there were
> (I think) 7 different C compilers running on the early port of Ultrix. That
> number, I think, did not include the port of gcc that DEC was funding
> outside the company.
>
> Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> semiconductor group, where he had worked on randomized testing for hardware
> verification. With all the compilers available, he decided to hack up a
> program to generate random small C programs with computable expected
> outputs. His program then compiled the random code with each compiler and
> tested the result. After finding a number of bugs this way, he got tired of
> submitting the bug reports, and changed his program to write and submit the
> bug reports automatically.
>
> This caused a little bit of consternation with some of the compiler teams
> at first.
>
> Eventually, this led to some collaboration with the DEC languages and
> tools team, and Bill McKeeman published a paper that line of work in the
> Digital Technical Journal in 1998[1].
>
>  - Win
>
> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf


Does this software still exist anywhere?  The link to the download is long
gone, archive.org did not preserve the download, and I had no success
finding the files on the web.

-Henry

[-- Attachment #2: Type: text/html, Size: 2685 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] DEC Compilers (was: Re: SDB debugger
  2020-05-05 17:36             ` Paul Winalski
  2020-05-05 18:53               ` Dr Iain Maoileoin
@ 2020-05-05 21:59               ` Dan Cross
  1 sibling, 0 replies; 31+ messages in thread
From: Dan Cross @ 2020-05-05 21:59 UTC (permalink / raw)
  To: Paul Winalski; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Tue, May 5, 2020 at 1:37 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 5/4/20, Win Treese <treese@acm.org> wrote:
> >
> > Andy Payne, a recent hire at the lab, had been an intern in DEC’s
> > semiconductor group, where he had worked on randomized testing for
> hardware
> > verification. With all the compilers available, he decided to hack up a
> > program to generate random small C programs with computable expected
> > outputs. His program then compiled the random code with each compiler and
> > tested the result. After finding a number of bugs this way, he got tired
> of
> > submitting the bug reports, and changed his program to write and submit
> the
> > bug reports automatically.
> >
> > This caused a little bit of consternation with some of the compiler
> teams at
> > first.
>
> I remember that very well.  IIRC it was called fuzz testing, and
> indeed it was controversial, for the reasons Bill McKeeman discusses
> in his paper. [1]  On the one hand, compiler developers said, "nobody
> would ever write something like that--we can't waste our time on these
> issues when there are real bugs waiting to be fixed."  On the other
> hand, some of the bugs that fuzz testing turned up provoked reactions
> such as, "OMG!  THAT caused the compiler to crash?"  I think the
> turning point was when fixing one of the fuzz testing bugs also fixed
> an obscure and hard-to-debug customer problem.  Intel's C and Fortran
> compiler team has also used random testing technology.
>

Ah, very cool. The same approach has come into favor again recently. I've
dealt personally with https://github.com/google/syzkaller, which is a
kernel fuzzer that generates random inputs to system calls and detects e.g.
panics. It's a neat approach.

        - Dan C.

> [1] https://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf
>
> -Paul W.
>

[-- Attachment #2: Type: text/html, Size: 2716 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-01 20:48 [TUHS] SDB debugger Paul Ruizendaal
                   ` (2 preceding siblings ...)
  2020-05-02  0:49 ` Noel Hunt
@ 2020-05-12  4:15 ` Dave Horsfall
  3 siblings, 0 replies; 31+ messages in thread
From: Dave Horsfall @ 2020-05-12  4:15 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

On Fri, 1 May 2020, Paul Ruizendaal wrote:

> - On 6th edition the debugger was ‘cdb’

I thought it was straight "db"...

-- Dave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03 16:16   ` Rich Morin
@ 2020-05-12  4:36     ` Dave Horsfall
  0 siblings, 0 replies; 31+ messages in thread
From: Dave Horsfall @ 2020-05-12  4:36 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sun, 3 May 2020, Rich Morin wrote:

>> On May 2, 2020, at 10:45, Larry McVoy <lm@mcvoy.com> wrote:
>>
>> ... But truth be known, I'm sort of a printf() debugger.  ...

[...]

As am I, but the bug sometimes disappears :-(  Code offsets, or something?

-- Dave

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02 17:45 ` Larry McVoy
@ 2020-05-03 16:16   ` Rich Morin
  2020-05-12  4:36     ` Dave Horsfall
  0 siblings, 1 reply; 31+ messages in thread
From: Rich Morin @ 2020-05-03 16:16 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

> On May 2, 2020, at 10:45, Larry McVoy <lm@mcvoy.com> wrote:
> 
> ... But truth be known, I'm sort of a printf() debugger.  ...

So am I, and ISTR Brian Kernighan and Larry Wall saying that they are, as well.  Over the years, I've written some scripts to make this less painful.  For example, in Ruby, I use the et() script, as written up in http://wiki.cfcl.com/Projects/Ruby/Phone_Home:

l = %w[ context~  dir_path#  file_path foo.bar  bar[:baz] ]
et(l)

This produces the following output:

some_script:72:in `main'
  context      { :foo => "yada yada yada", ... }
  file_path    "a/b/c"
  foo.bar      :warn
  bar[:baz]    42

I also have a tiny Elixir script, ii/2, which works nicely in pipelines:

...
|> ii(:foo)
...

-r


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03  2:41 ` Larry McVoy
@ 2020-05-03  7:14   ` arnold
  0 siblings, 0 replies; 31+ messages in thread
From: arnold @ 2020-05-03  7:14 UTC (permalink / raw)
  To: norman, lm; +Cc: tuhs

Larry McVoy <lm@mcvoy.com> wrote:

> I really don't know how systems people do it these days, it is a
> much more complex world.
>
> ...  these days, I have no idea how I'd make a difference.

By doing something besides systems. There are tons of open source
projects at the user level that make a difference. Consider something
like AsciiDoc.  Less than 10 years old (methinks), and in use for
production by at least one major technical publisher that I know of.
(And it sure beats the pants off of DocBook XML.)

Or the work I do on gawk, Chet on Bash, other GNU bits.

There's a whole world out there besides just the kernel.

Arnold

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03  2:21 Norman Wilson
  2020-05-03  2:41 ` Larry McVoy
@ 2020-05-03  3:05 ` Rob Pike
  1 sibling, 0 replies; 31+ messages in thread
From: Rob Pike @ 2020-05-03  3:05 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

I am happy to learn that there is at least one other person who likes that
rule. It's never really caught on, which mystifies me. There is some
progress, but people are too enamored by animations using cursor addressing
to appreciate the elegance of editable typescripts.

-rob

[-- Attachment #2: Type: text/html, Size: 343 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-03  2:21 Norman Wilson
@ 2020-05-03  2:41 ` Larry McVoy
  2020-05-03  7:14   ` arnold
  2020-05-03  3:05 ` Rob Pike
  1 sibling, 1 reply; 31+ messages in thread
From: Larry McVoy @ 2020-05-03  2:41 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

On Sat, May 02, 2020 at 10:21:04PM -0400, Norman Wilson wrote:
> I wish it was as easy for others to have such
> satisfaction these days.

Amen to that.  I think we all lived, you Bell Labs people especially,
in a simpler time.  We were trying to fit into 64K, split I/D 128K,
my Z80 was 64K but some extra for graphics, then the VAX came and we
were trying for 1MB, Suns with 4MB.

So small mattered a lot and that meant the Unix philosophy of do one
thing and do it well worked quite nicely.

What that also meant, to people coming on a little bit after, was that
it was relatively easy to modify stuff, the stuff was not that complex.

Even I had an easy time, my prime was back at Sun when SunOS was a
uniprocessor OS.  That is dramatically simpler than a fully threaded
SMP OS that has support for TCP offloading, NUMA, etc, etc.

I really don't know how systems people do it these days, it is a
much more complex world.

So I'm with Norm, it was fun back in the day to be able to come in
and have a big impact.  I too wish that it was as easy for young
people to come in and have that impact.  I've done that and it was
awesome, these days, I have no idea how I'd make a difference.

--lm

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
@ 2020-05-03  2:21 Norman Wilson
  2020-05-03  2:41 ` Larry McVoy
  2020-05-03  3:05 ` Rob Pike
  0 siblings, 2 replies; 31+ messages in thread
From: Norman Wilson @ 2020-05-03  2:21 UTC (permalink / raw)
  To: tuhs

Doug's list is slightly off:

adb	v7-v10
sdb	v8-v10

sdb may actually have been in V7; I'm quite sure
it was present in 32/V.  But it's not in the V7
manual.

adb and sdb were certainly working fine when I
arrived in 1127, but they still used ptrace
because nobody wanted to touch the code.  I used
adb quite often (still would were it available
in modern worlds!), so I cared enough to take
it over, restructuring it quite a bit to make it
easier to retarget for different instruction
sets and byte orders, and of course to use /proc.
I also made some trivial, compatible changes to
how numbers were read and printed to conform to
Rob's Rule (of which I am also a fan) that what
a program presents as output it should also
accept as input.

sdb I wasn't as fond of, but I did want to get
rid of ptrace, so I tinkered it just enough to
accomplish that.

I do remember clearly celebrating the death of
ptrace by removing ptrace(2) from the copy of the
V8 manual in the UNIX Room.  It took up two
pages, and they happened to be facing pages,
so I glued them together.

I wish it was as easy for others to have such
satisfaction these days.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
  2020-05-02  2:52 Doug McIlroy
@ 2020-05-02 17:45 ` Larry McVoy
  2020-05-03 16:16   ` Rich Morin
  0 siblings, 1 reply; 31+ messages in thread
From: Larry McVoy @ 2020-05-02 17:45 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs

So I definitely remember adb, I liked it for the same reasons that Rob
did, it told you the truth.

I also remember using a sdb debugger, not sure if it was at Sun or 
when I was doing a Sys V port.  I liked it, it was reasonable.

I think dbx ended up becoming the one I used on BSD.  Gdb eventually
got good enough but I'm with Rob, it was a mess early on.

But truth be known, I'm sort of a printf() debugger.  The main thing
I use gdb for is a stack trace, that's usually enough.  The BitKeeper
source has this "gem":

void
gdb_backtrace(void)
{
        FILE    *f;
        char    *cmd;

        unless (getenv("_BK_BACKTRACE")) return;
        unless ((f = efopen("BK_TTYPRINTF")) ||
            (f = fopen(DEV_TTY, "w"))) {
                f = stderr;
        }
        cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d 2>&%d",
            bin, getpid(), fileno(f), fileno(f));

        system(cmd);
        free(cmd);
        if (f != stderr) fclose(f);
}


On Fri, May 01, 2020 at 10:52:49PM -0400, Doug McIlroy wrote:
> >  Does anyone know if dbx ended up 8 or 9th
> 
> I believe the only debuggers on research machines were
> db      v1-v6
> adb     v7,v9,v10
> cdb     v3-v6
> sdb     v8-v9
> pi      v8-v10
> 
> Doug

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [TUHS] SDB debugger
@ 2020-05-02  2:52 Doug McIlroy
  2020-05-02 17:45 ` Larry McVoy
  0 siblings, 1 reply; 31+ messages in thread
From: Doug McIlroy @ 2020-05-02  2:52 UTC (permalink / raw)
  To: tuhs

>  Does anyone know if dbx ended up 8 or 9th

I believe the only debuggers on research machines were
db      v1-v6
adb     v7,v9,v10
cdb     v3-v6
sdb     v8-v9
pi      v8-v10

Doug

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2020-05-12  4:37 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-01 20:48 [TUHS] SDB debugger Paul Ruizendaal
2020-05-01 21:57 ` Clem Cole
2020-05-02  9:10   ` Paul Ruizendaal
2020-05-02 16:04     ` Clem Cole
2020-05-01 23:05 ` Jeremy C. Reed
2020-05-02  0:49 ` Noel Hunt
2020-05-02  1:22   ` Rob Pike
2020-05-02  3:49     ` Noel Hunt
2020-05-02 20:16   ` Paul Ruizendaal
2020-05-03  6:58     ` arnold
2020-05-03 16:13     ` Clem Cole
2020-05-03 16:53       ` Henry Bent
2020-05-03 17:06         ` Henry Bent
2020-05-03 17:13       ` Henry Bent
2020-05-03 20:26         ` Clem Cole
2020-05-05  0:22           ` [TUHS] DEC Compilers (was: " Win Treese
2020-05-05 17:36             ` Paul Winalski
2020-05-05 18:53               ` Dr Iain Maoileoin
2020-05-05 21:59               ` Dan Cross
2020-05-05 21:49             ` Henry Bent
2020-05-03 17:35       ` [TUHS] " Paul Winalski
2020-05-03 21:27       ` Paul Ruizendaal
2020-05-12  4:15 ` Dave Horsfall
2020-05-02  2:52 Doug McIlroy
2020-05-02 17:45 ` Larry McVoy
2020-05-03 16:16   ` Rich Morin
2020-05-12  4:36     ` Dave Horsfall
2020-05-03  2:21 Norman Wilson
2020-05-03  2:41 ` Larry McVoy
2020-05-03  7:14   ` arnold
2020-05-03  3:05 ` Rob Pike

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).