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(a)planet.nl> wrote:

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(a)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. > > > -rob > > > On Sat, May 2, 2020 at 10:50 AM Noel Hunt <noel.hunt(a)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(a)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? >>> >>> >>> >>>

Paul Ruizendaal <pnr(a)planet.nl> wrote: 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

On Sun, 3 May 2020 at 12:14, Clem Cole <clemc(a)ccc.com> wrote: 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

On Sun, 3 May 2020 at 12:14, Clem Cole <clemc(a)ccc.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. -Henry

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

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.

On Mon, 4 May 2020 at 20:33, Win Treese <treese(a)acm.org> wrote: 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

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.