Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucla-cs!admin.cognet.ucla.edu!casey
From: casey@admin.cognet.ucla.edu (Casey Leedom)
Newsgroups: comp.sys.apollo
Subject: Re: adb missing ...
Keywords: adb, dbx machine level facilities
Message-ID: <15687@shemp.CS.UCLA.EDU>
Date: 1 Sep 88 09:49:29 GMT
References: <8808291425.AA04608@richter.mit.edu> <3e3043cd.12edf@apollo.COM>
Sender: news@CS.UCLA.EDU
Reply-To: casey@cs.ucla.edu (Casey Leedom)
Organization: UCLA
Lines: 28

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