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 25946 invoked from network); 2 May 2020 01:23:21 -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 01:23:21 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DF5779C8AF; Sat, 2 May 2020 11:23:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 938B99C853; Sat, 2 May 2020 11:22:45 +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="cO6AFAU0"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 162F19C853; Sat, 2 May 2020 11:22:43 +1000 (AEST) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by minnie.tuhs.org (Postfix) with ESMTPS id D7D889C851 for ; Sat, 2 May 2020 11:22:38 +1000 (AEST) Received: by mail-vs1-f53.google.com with SMTP id h30so7434713vsr.5 for ; Fri, 01 May 2020 18:22:38 -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=HXwjdXpHCh5ONs3T+pnDWe6JpPSEbYcS5wo0pH4qXkE=; b=cO6AFAU0V9lCoVYOeY19CTSrXvcCbwy3Pji6w74YPrep6RCB5DMKBAQ/hoe4KKW0OX hcyNBRExgOOGwRJTO3nbvQXFV2E1mVqC5E+fl795BIC80N/tDhAb0+y+xWT/IOu8o5Xd k/vmxTRtIJBIO6QNMQLy35AHE5NOYjDrwOVWIloD0NGXzfsshjolDkkzNUD99zDnUFvQ S8LY7zlYrf4ioqsUd2CjOMVAnI6U3ls3HppSY8xRYC+uDq0vvTSEHDEAFDj4lNkC7ptZ W9LuNG+8svO5bk75AwYY1YIBbL2vvyGePSzo9QrtW4Is7fKk79bLYuorVLYefWRl9Mj0 Uo/Q== 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=HXwjdXpHCh5ONs3T+pnDWe6JpPSEbYcS5wo0pH4qXkE=; b=kZXYPGK3C7pW9ioZtGaIwgZXD2vEWO3VogbxRcHX5dWvMCASa7N2J26PAZZc9ybWZx edhP4WCIfoUq2sQ8cy7kRchg6ag1bq19NfEiqaEr03QS86qJISi98agwPAQtBs2u+TUL X3dc2iZX9WS95NIQOWxfq5NViZeyRv12kGrErs+xZ0Fu9vTN288hECr5ta8y+YejEdyE Z9TLop+CPR5b0UDWyHdGzN6utyhvmvTDeLDHqXZyYKIAp3cU1TGgmdszPgF3+S2q91r9 RUmSo5hl7qoeMPL00hsj43pvvP29o56h3HhHEgC6rHfpZ/v1mt+8lJVWQIabeWcVGSHH lcag== X-Gm-Message-State: AGi0PuartIV/7ZtRPkthQsdK+zCxR8Git7c9NZ/vAOoIWv88MsDQzgmg fZqLlGBiCDvqTUDDvR3Y20d2PKmv3ufPtkyx/+k= X-Google-Smtp-Source: APiQypKQdT+tHEUblPZxHKheoEqSUHTzK6EkbGlm2tAlUFmT164DQXE2+fkITL5nYuHNav1IGQs4Pw1HwDwdemd9OhY= X-Received: by 2002:a67:f9d0:: with SMTP id c16mr5313804vsq.53.1588382556356; Fri, 01 May 2020 18:22:36 -0700 (PDT) MIME-Version: 1.0 References: <2F4C604D-F01C-4A82-948A-7E77093B48A1@planet.nl> In-Reply-To: From: Rob Pike Date: Sat, 2 May 2020 11:22:25 +1000 Message-ID: To: Noel Hunt Content-Type: multipart/alternative; boundary="0000000000000a031d05a4a02284" 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" --0000000000000a031d05a4a02284 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 fro= m =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 reworke= d 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 r= elated 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 th= at 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 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 =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 b= ack ported to 16 >> bit Unix, not in the SysIII line and not in the 2.xBSD line. It would se= em >> to me that the simple stabs format of 32V would have lent itself to bein= g >> back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool >> chain and debugger? >> >> >> >> --0000000000000a031d05a4a02284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't remember dbx appearing in our lab, but that do= esn'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 bu= gs, to make it actually work in Plan 9. I had several conversations with St= eve 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 c= are because it was lower level than cdb/sdb/gdb. I liked it because, once t= hose 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=C2=A0 dumped core for the nth time on top of the core I was debugg= ing, 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.
<= br>
The sdb/gdb line also had a peculiar property of not answerin= g 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 mak= es catching a dropped bag of concrete mix.

One deb= ugger 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 interact= ive tool, was Phil Winterbottom's Acid. It has a crazy language but onc= e 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 gr= eat for displaying multithreaded program stacks.

P= i 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 Cargi= ll'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 Rui= zendaal <pnr@planet.n= l> wrote:
Reading some more stuff about the road from 7th Edition to 8th Edition, th= is 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 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?



--0000000000000a031d05a4a02284--