The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Noel Hunt <noel.hunt@gmail.com>
To: Rob Pike <robpike@gmail.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>, Paul Ruizendaal <pnr@planet.nl>
Subject: Re: [TUHS] SDB debugger
Date: Sat, 2 May 2020 13:49:24 +1000	[thread overview]
Message-ID: <CAGfO01zoGVKwdQ83AMUB8Gjzm4Jov__-fefcqe_vpTMt_z2ZDA@mail.gmail.com> (raw)
In-Reply-To: <CAKzdPgyeL9=CrxYuc_KCRy7MZEQGzgnpLGfFFawvnXJF7Rc2SA@mail.gmail.com>

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

  reply	other threads:[~2020-05-02  3:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 20:48 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfO01zoGVKwdQ83AMUB8Gjzm4Jov__-fefcqe_vpTMt_z2ZDA@mail.gmail.com \
    --to=noel.hunt@gmail.com \
    --cc=pnr@planet.nl \
    --cc=robpike@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).