From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 9552 invoked from network); 2 May 2020 03:50:34 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 May 2020 03:50:34 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2B6329C8C0; Sat, 2 May 2020 13:50:29 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A8B9C9C851; Sat, 2 May 2020 13:49:53 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="DOgo7Rh2"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 761E99C851; Sat, 2 May 2020 13:49:51 +1000 (AEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by minnie.tuhs.org (Postfix) with ESMTPS id 91C679C733 for ; Sat, 2 May 2020 13:49:50 +1000 (AEST) Received: by mail-wm1-f46.google.com with SMTP id v8so11057251wma.0 for ; Fri, 01 May 2020 20:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mwUy1kWMPxr14qFjKDqH9pDkb1wHfHDQRNgUMXVDYYo=; b=DOgo7Rh2rhyEeq25p6EdrK1Zoq2sMRR9DBGa2oXArqsfXyBpF3ipC4CPb1Aj52lbQ9 Iw/SxF9N7jvtncfwclqGdwqvXOIKE1HGwRb0KJUKrnMxs2gW2y6eYef7LBtad0tao+c2 mDUFNp9wkkYaQtqnh9kRx6CJnoWWFFDue6js27t1uIjzfvQ2Xt85nIZTTctTP4lcezgM buGGOQ5PEVMVg6RW2T9nauIkZPdzAZeabn2qm72sD1xgQhHitXzDyuovG8DCs5YZuKri po74q2OPAMulArhxCMsLUeCEiuiOdrYeqGJP4+Z/9AIPr9p0zCynoUVrqS6/3a2+1o2S wQaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mwUy1kWMPxr14qFjKDqH9pDkb1wHfHDQRNgUMXVDYYo=; b=QwqU16DqlOITKSfYDgL3V42hJ13+XxmxV/pb+Kg3jYhXNsUO0SHE93SL89V8MXJA+X bSpCyhrRpEgJG6bJMB+Y8z214qQq9I5bnVoXNdJaS5uTS8cnc0pYSHJoaWuhRjUN/+fz Vgz+tYasTFp2LrPl5yWYhJlEC8CIxA4ERy1mY/isuIQYs7Kq90NWTrxhfjrPeN/NhFHI VptQsFAtJjZd9BjLitUztoAVaQB+g2cKwH+lJfSRP56zuuNif4/u3EnEf9Ju3e0zjpo1 SUs6qbhZUtEqmBr+2QA4GcLADZnnh4usCJ3mLMCeTCOScJlUgI17z3zGnjUBqPAvrn5q NVCA== X-Gm-Message-State: AGi0Pua0I+l7n9Z8nsgLigJZwHU7cbnm3alPIw4LAbjI3Y2wmwG135CW NKuLwZT3Cv6kZM3BLWr5oX76SNmv3WLrVZLtmvKVHRws X-Google-Smtp-Source: APiQypJ50odVSObrxZkU3hyCrGX9E2fThJ9SjWt04tjh23aJokZAtQyyraCNZtIi0n9ISxdzPCJbBolEXrH3Wv54/dI= X-Received: by 2002:a1c:b684:: with SMTP id g126mr2435011wmf.163.1588391389240; Fri, 01 May 2020 20:49:49 -0700 (PDT) MIME-Version: 1.0 References: <2F4C604D-F01C-4A82-948A-7E77093B48A1@planet.nl> In-Reply-To: From: Noel Hunt Date: Sat, 2 May 2020 13:49:24 +1000 Message-ID: To: Rob Pike Content-Type: multipart/alternative; boundary="00000000000085218305a4a23049" Subject: Re: [TUHS] SDB debugger X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Paul Ruizendaal Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000085218305a4a23049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 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 sever= al > 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 yesteryea= r > was far too unreliable and crashy for me. After it dumped core for the n= th > 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 probabl= y > 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 no= w > 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 fo= r > 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 b= ut > once you licked it (I think the only three who did were Phil, me, and Rus= s > 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 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 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 =E2=80=98cdb=E2=80=99 >>> >>> - On 7th edition it was =E2=80=98adb=E2=80=99, a rewrite / evolution fr= om =E2=80=98cdb=E2=80=99 >>> >>> - In 32V a new debugger appears, =E2=80=98sdb=E2=80=99. Its code seems = a derivative from >>> =E2=80=98adb=E2=80=99, but the command language is substantially rework= ed and it uses a >>> modified variant of the a.out linker format - in essence the beginnings= of >>> =E2=80=98stabs=E2=80=99. 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 =E2=80=99sdb' files t= hat 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 =E2= =80=98VAX >>> only=E2=80=99. With these roots, it is not surprising that it is also i= n 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 =E2=80=98sdb=E2=80=99= is unknown. Is that >>> correct, is the author really unknown? >>> >>> (2) As far as I can tell, the =E2=80=99sdb=E2=80=99 debugger was never = back ported to 16 >>> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would s= eem >>> to me that the simple stabs format of 32V would have lent itself to bei= ng >>> back ported. Is it correct that no PDP11 Unix used (a simple) stabs too= l >>> chain and debugger? >>> >>> >>> >>> --00000000000085218305a4a23049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Pi was cool, but that was earlier and tied to the Jerq/Blit and C++.

I believ= e Dave Kapilow kept up development of pi at Bell,
long after Tom Cargill= =C2=A0had left research. There= is a CDROM
of pi as of about 2002, with versions=C2=A0compilable for various
=
architectures, but the terminal part, which was actually=C2=A0'pads',
origina= lly Blit graphics,=C2=A0was re= placed with Openlook. It isn't
hard to get=C2=A0<= span style=3D"font-family:monospace">pads working with the Plan graphics mo= del.

The problem with that distribution is that it is still all
stabs-based, and although=C2=A0dwarf is a nightmare, being able to
read dwarf symbol tabl= es in pi would be a=C2=A0pleas= ing step forward.
Dealing with dwarf is a struggle, but Russ= Cox and Rob=C2=A0Pike have
written perhaps the only sane code in the world to deal with t= he
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 rememb= er 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 fi= nishing things up and fixing a lot of bugs, to make it actually work in Pla= n 9. I had several conversations with Steve Bourne about it to understand w= hy it seemed broken, and how to fix it. Once fixed, It could do some remark= able 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 ri= ght answer, something gdb never did back then. The [scg]db of yesteryear wa= s far too unreliable and crashy for me. After it=C2=A0 dumped core for the = nth time on top of the core I was debugging, I gave up on it. But I was nev= er 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, alt= hough I don't remember the details. It was more interested in the symbo= ls than the code, and that could get in the way. The failure of the compile= r 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 concre= te mix.

One debugger that we used a lot, although = more as a scripting language for things like tracing system calls and check= ing 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 t= hree who did were Phil, me, and Russ Cox) it was very powerful. Acme had so= me front-end code for it that made it great for displaying multithreaded pr= ogram stacks.

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

-rob

On Sat, May 2, 2020 at 10:50 AM Noel Hunt <noel.hunt@gmail.com> wrote:
<= /div>
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 fo= r 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:<= br>
Reading some mor= e stuff about the road from 7th Edition to 8th Edition, this time about deb= uggers.

My current understanding is as follows:

- On 6th edition the debugger was =E2=80=98cdb=E2=80=99

- On 7th edition it was =E2=80=98adb=E2=80=99, a rewrite / evolution from = =E2=80=98cdb=E2=80=99

- In 32V a new debugger appears, =E2=80=98sdb=E2=80=99. Its code seems a de= rivative from =E2=80=98adb=E2=80=99, but the command language is substantia= lly reworked and it uses a modified variant of the a.out linker format - in= essence the beginnings of =E2=80=98stabs=E2=80=99. Of course the compiler,= assembler, linker and related tools all emit/recognize these new symbol ta= ble elements.

- The July 78 file note by London/Reiser does not mention a reworked debugg= er at all; the 32V tape that is on TUHS has =E2=80=99sdb' files that ar= e dated Feb/Mar 1979. This stuff must have been developed between July 78 a= nd March 79.

- In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respective= ly) the stabs format is more developed. For SysIII it is =E2=80=98VAX only= =E2=80=99. With these roots, it is not surprising that it is also in 8th Ed= ition.


Two questions:

(1) According to Wikipedia the original author of the stabs format is unkno= wn. It also says that the original author of =E2=80=98sdb=E2=80=99 is unkno= wn. Is that correct, is the author really unknown?

(2) As far as I can tell, the =E2=80=99sdb=E2=80=99 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 its= elf to being back ported. Is it correct that no PDP11 Unix used (a simple) = stabs tool chain and debugger?



--00000000000085218305a4a23049--