paul@DELRIO.CC.UMICH.EDU ('da Kingfish) (08/24/88)
What? No adb? Let's see what I have on my node for adb ... % ls -l /bin/adb lrwxrwxrwx 1 root 17 Aug 24 00:56 /bin/adb -> /usr/lib/sendmail % It's what I find all my bugs with. Well, let's sum up the Casey reports: Keywords: keyboard, auto-repeat, apollo, brain damage Keywords: reincarnation, sin, punishment, Hell on Earth, Apollo Domain-IX Keywords: Total idiocy, useless miscreates, cannon fodder, <unprintable> Are going to be interviewing with tektronix or boeing when you graduate? Just wondering. --paul
casey@admin.cognet.ucla.edu (Casey Leedom) (08/25/88)
In article <8808240515.3e0b20b76000.c6e5@delrio.cc.umich.edu> paul@DELRIO.CC.UMICH.EDU ('da Kingfish) writes: > > What? No adb? Let's see what I have on my node for adb ... > > % ls -l /bin/adb > lrwxrwxrwx 1 root 17 Aug 24 00:56 /bin/adb -> /usr/lib/sendmail The point is that sometimes you need to be able to see what instructions have been generated and dbx is a pig to do that with. I spent most of an hour fighting with dbx trying to get it to just give me a simple disassembly of a function that was behaving strangely. If someone will incorporate adb's facilities into dbx, then it's fine to toss adb, but not until then. And I'm not at all sure that's it's reasonable to merge the two debuggers. I'd have to give that more thought. > Well, let's sum up the Casey reports: > > Keywords: keyboard, auto-repeat, apollo, brain damage > Keywords: reincarnation, sin, punishment, Hell on Earth, Apollo Domain-IX > Keywords: Total idiocy, useless miscreates, cannon fodder, <unprintable> > > Are going to be interviewing with tektronix or boeing when you > graduate? Just wondering. The litmus test will be the tenor of my comments after we get SR10. From everything I've heard, it addresses most of my complaints. At this point I've made a very uneasy peace with my workstation: I only use it as a semi-intelligent terminal and it in return doesn't screw with my head too badly. It was an enormous improvement when I ditched DM and started using X11R2. As for graduating, that event may never transpire. I assume by your question that Tektronix and Boeing are extensive users of Apollos? I'll wait till SR10 before applying ... :-) Casey
lee@ssc-vax.UUCP (Lee Carver) (08/26/88)
Thanks, Paul, for collecting this clap-trap from casey. paul@DELRIO.CC.UMICH.EDU ('da Kingfish) writes: > Well, let's sum up the Casey reports: > > Keywords: keyboard, auto-repeat, apollo, brain damage > Keywords: reincarnation, sin, punishment, Hell on Earth, Apollo Domain-IX > Keywords: Total idiocy, useless miscreates, cannon fodder, <unprintable> After hearing some college students gripe about this machine and that OS, and working hard to make a very archic system kick butt, it struck me that the RIGHT point of view is: The question is not whether its a piece of crap, The question is, can you make the piece of crap hu? Apollos, DECs (VAXen, PDP-11, 10s), IBMs (PCs, mainframes), etc. are crap. Precisely, they all have some ugly features, like non-transportability. UNIX, MS-DOS, TOPS-10, VM/CMS, MVS/XA, CICS, Aegis, RTE-IV, etc. are crap. Precisely, they all have some ugly features, like non-transportability. QUIT YER GRIPING AND MAKE THE SYSTEM WORK!! QUIT BEING LAZY, AND TAKE SOME PRIDE!! SOFTWARE IS HARD WORK!!
rreed@mntgfx.mentor.com (Robert Reed) (08/28/88)
In article <15476@shemp.CS.UCLA.EDU> casey@admin.cognet.ucla.edu.UUCP (Casey Leedom) writes:
As for graduating, that event may never transpire. I assume by your
question that Tektronix and Boeing are extensive users of Apollos? I'll
wait till SR10 before applying ... :-)
Well, when I left Tektronix, the majority of Apollos were in CAE Systems
Division, and you obviously don't need to worry about them any more :-)krowitz@RICHTER.MIT.EDU (David Krowitz) (08/29/88)
I believe I saw a message a while ago about an undocumented switch (of course!) to DBX which allowed you to debug the machine code. I think the switch was -DB (or maybe it was the command DB give after you started DEBUG, I can't remember which). If someone has been keeping an archive of the postings, maybe they can search back through them. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
geof@imagen.UUCP (Geoffrey Cooper) (08/31/88)
In article <8808291425.AA04608@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: > I believe I saw a message a while ago about an undocumented switch > (of course!) to DBX which allowed you to debug the machine code. I It is the undocumented "db" command in "DEBUG". I've used it to solve a few head scratchers (e.g., NULL redefined to -1 at a random position in a large source file). Commands include: HELP (how I found this out) ACCESS (memory/register at given address) SS - single step WALK - do N single steps. QUIT - exit back to debug. - Geof-- UUCP: {decwrl,sun}!imagen!geof ARPA: imagen!geof@decwrl.dec.com
pato@apollo.COM (chc 02 rd) (08/31/88)
In article <8808291425.AA04608@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >I believe I saw a message a while ago about an undocumented switch >(of course!) to DBX which allowed you to debug the machine code. I >think the switch was -DB (or maybe it was the command DB give after >you started DEBUG, I can't remember which). If someone has been >keeping an archive of the postings, maybe they can search back >through them. > > > -- David Krowitz The domain/ix and domain/os is the standard bsd4.3 DBX augmented to provide source file display (a la /com/debug) and modified to understand a 68000 architecture instead of a VAX architecture. DBX always allows you to debug machine code. To examine disassembled machine instructions use: (dbx) <location>/<number>i /* prints <number> machine instructions ** beginning at location <location> */ e.g., (dbx) 0xb50a /5i 0000b50a LINK.w a6,#-8 0000b50e MOVEM.l d2-d6/a2-a5,-(a7) 0000b512 MOVEA.l a0,a5 0000b514 MOVE.l (8.w,a6),d3 0000b518 MOVEA.l (C.w,a6),a2 or (dbx) &main/3i /* main is a function in the program :-) */ 0000b50a LINK.w a6,#-8 0000b50e MOVEM.l d2-d6/a2-a5,-(a7) 0000b512 MOVEA.l a0,a5 or (dbx) ($pc)/3i /* $pc is the program counter */ 0000b51e PEA.l (1A44.w,a5) 0000b522 MOVEA.l (-7AC.w,a5),a0 0000b526 JSR (a0) "stepi" is the command for stepping by instructions, similarly stopi, tracei, nexti $pc is the program counter $a0 ... $a7 are the address registers $d0 ... $d7 are the data registers $sp is an alias for $a7 $db is an alias for $a6 The manual page for dbx describes these facilities under the section "Machine Level Commands". The only thing that it seems to be missing is the the definition of the 68000 registers instead of the VAX register set. Joe Pato UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato Apollo Computer Inc. NSFNET: pato@apollo.com
casey@admin.cognet.ucla.edu (Casey Leedom) (09/01/88)
In article <3e3043cd.12edf@apollo.COM> pato@apollo.COM (Joe Pato) writes: > The domain/ix and domain/os is the standard bsd4.3 DBX augmented to > provide source file display (a la /com/debug) and modified to understand > a 68000 architecture instead of a VAX architecture. DBX always allows > you to debug machine code. > > The manual page for dbx describes these facilities under the section > "Machine Level Commands". The only thing that it seems to be missing is > the the definition of the 68000 registers instead of the VAX register set. Except that dbx's machine level facilities are pathetic. When I try to display a chunk of code it says "program is not active". I have to start the friggin' program just to look at it! When I finally do get it started and start looking at things, it prints everything out via it's absolute address instead of a symbol plus an offset. And, in fact, it never seem to print anything symbolically. Dbx's machine level facilities are basically just to complement its symbolic facilities. They are no substitute for the facilities offered by adb. I'm trying to use /com/debug right now, but it doesn't look any better (though it does offer some interesting capabilities - namely cross process debugging). Please implement adb. Alternatively, incorporate adb's capabilities into dbx (and then send your source to Berkeley so we can all ditch adb as a separate debugger). Personally I think the first option is easier. Casey
ok@quintus.uucp (Richard A. O'Keefe) (09/02/88)
In article <15687@shemp.CS.UCLA.EDU> casey@cs.ucla.edu (Casey Leedom) writes: > Except that dbx's machine level facilities are pathetic. When I try to >display a chunk of code it says "program is not active". I have to start >the friggin' program just to look at it! When I finally do get it >started and start looking at things, it prints everything out via it's >absolute address instead of a symbol plus an offset. And, in fact, it >never seem to print anything symbolically. This is not true of all versions of dbx. For example, I just did % dbx payste # payste is a program of mine (dbx) &main+0x1a/3i # print 3 instrs starting at "main"+1a and it printed main+0x1a: tstl d0 main+0x1c: beqs main+0x68 main+0x1e: pea a6@(-0xf0) Mind you, this was SunOS 3.2 on a Sun-3/50, but exactly the features are described in the ULTRIX manual page for dbx. Is the Apollo one different?