Hi folks;

Recently I feel like I've become the de facto ddb maintainer.  Whether
that's true or not ("if the shoe fits, wear it"), as a result of cgd
pointing out that "xf" and "xb" might exist in Mach, I went on a
hunting expedition for Mach ddb source, and was relatively surprised
by the state of what I found.

Mach development at CMU on ddb seems to've taken place from roughly
July of 1990 through December of 1994. 386BSD pulled a snapshot of
that development from 14 February 1991, and that was imported
unchanged into NetBSD (and probably FreeBSD). The last release of Mach
3 (MK81?) I can find took a snapshot of development from 18 May
1993. The publically available Mach4-UK02p21 and Mach4-UK22
distributions are harder to date since they stripped out version
information (sigh), but look like they are the same as what was in
Mach 3. Substantial changes to ddb happened between the 386BSD
snapshot and the end of work on DDB, and it would be nice to see them
in NetBSD.

Before I itemize the changes I expect to see, I'd like to note two
changes that affect the existing interface:

     1) "ditto" (last address explicitly specified) in our
     implementation is the double-quote ("), even though our manpage
     documents it as the comma (,) [looks like an error in the -mandoc
     conversion]. I'd like to change it to the single-quote ('), as
     that's what Mach uses now. Mach took this change in July of 1991
     from the Takashi Nishikado at OSF.

     On the other hand, it might make more sense to changes pick a different
     character, due to complexities of parsing " for quoted strings
     and ' for adb-style string literals (see below). Thoughts would
     be appreciated.


     2) Our prompt is currently one of:
             (cpu 1)db>                         (multiprocesor)
     or      db>                                (single processor)
     Mach ddb has used:
             db{1}>                             (multipocessor)
     or      db>                                (single processor)
     I'd like to change to the Mach notation. Both Mach and NetBSD added
     multi-cpu support independantly.

Neither of those is particularly critical, though; but now would be a good
time to speak up and object.


I'm aware of the following bugs/problems in our implementation:

i)	"dot", "next", and "last" are not set properly and are usually
	the same.
ii)	examine /m (hex + character dump) doesn't work.
iii)	A bunch of unimplemented C operators, especially bitwise-OR (|).
iv)	double-quote delimitted strings don't work in "print", nor do
	multiple arguments (like the manpage says)
v)	command history sometimes gets slightly confused
vi)	uvm_fault()s can loop infinitely (kern/10016)


I'd like to bring in the following features from Mach; I've appended
the manpage exceprts for them at the end of this message.

a)	"cond" -- conditionally execute a specified command on a breakpoint.
b)	macros ("macro", "dmacro", "show macro").
c)	!! command repetition (mostly unnecessary, just for consistency)


I'd like to bring in these features from other debuggers (e.g. {k,}adb):

1)	"continue" should honor _count as a number of breakpoints to ignore,
	just as ",5:c" ignores 5 breakpoints in adb.

2)	There should be a "step over" command (like :e in adb) that sets
	a breakpoint at the next instruction if the current instruction
	is a call (or jump?).

3)	Specification of up to 4 ASCII chars as a 32-bit number
	in an expression, like ' in adb:
	     'cccc'          ASCII value of up to 4 characters.
	I'm not sure what character to use for this, if the single-quote
	is used for ditto, and the double-quote for strings in "print".

4)	Some sort of "immediate" step-in, step-over keybindings, like [
	and ] in kadb (but not in adb):
	     [           Like :e in adb(1), but requires only  one  keys-
			 troke and no RETURN character.
	
	     ]           Like :s in adb(1), but requires only  one  keys-
			 troke and no RETURN character.
	Does this make people queasy?


And lastly, enchancements that don't fall into any of the above categories:

I)	"search" should display useful output (by default? with /v?)
	indicating success/failure rather than simply setting "dot".
	Perhaps verbose by default unless called from a macro (ugh?).

II)	kern/9544, some symbolic representation of boot flags
	suitable for documentation (esp. for RB_NOSYNC).

--jhawk

Mach manpage excerpts:

a)	"cond" -- conditionally execute a specified command on a breakpoint.

   cond #<number> [ <condition> <commands> ]

       Set or delete a condition for the break point specified by
       the 'number'.  If the 'condition' and 'commands' are null,
       the condition is deleted.  Otherwise the condition is  set
       for  it.   When the break point is hit, the 'condition' is
       evaluated.  The 'commands' will be executed if the  condi-
       tion  is  true  and  the  break point count set by a break
       point command becomes zero.  'commands' is a list of  com-
       mands  separated  by semicolons.  Each command in the list
       is executed in that order, but if a "continue" command  is
       executed,  the  command  execution  stops  there,  and the
       stopped thread resumes execution.  If the  command  execu-
       tion  reaches  the  end  of the list, and it enters into a
       command input mode.
       For example,

           set $work0 0
           break/Tu xxx_start $task7.0
           cond #1  (1)  set $work0 1; set $work1 0; cont
           break/T  vm_fault $task7.0
           cond #2  ($work0) set $work1 ($work1+1); cont
           break/Tu xxx_end $task7.0
           cond #3  ($work0) print $work1 " faults\n"; set $work0 0
           cont

       will print page fault counts from 'xxx_start' to 'xxx_end'
       in task7.

b)	macros ("macro", "dmacro", "show macro").

   macro <name> <commands>

       Define a debugger macro as 'name'.  'commands' is  a  list
       of  commands  to  be  associated  with  the macro.  In the
       expressions of the command list, a variable $argxx can  be
       used to get a parameter passed to the macro.  When a macro
       is called, each argument is evaluated  as  an  expression,
       and the value is assigned to each parameter, $arg1, $arg2,
       ...  respectively.  10 $arg variables are reserved to each
       level  of macros, and they can be used as local variables.
       The nesting of macro can be allowed up to 5 levels.
       For example,

           macro xinit set $work0 $arg1
           macro xlist examine/m $work0,4; set $work0 *($work0)
           xinit *(xxx_list)
           xlist
           ....

       will print the contents of a list starting from 'xxx_list'
       by each "xlist" command.

   dmacro <name>

       Delete the macro named 'name'.

   show macro [ <name> ]

       Show the definitions of macros.  If 'name'  is  specified,
       only  the definition of it is displayed.  Otherwise, defi-
       nitions of all macros are displayed.


c)	!! command repetition (mostly unnecessary, just for consistency)

       The general command syntax is:

           command[/modifier] address [,count]

       "!!" repeats  the  previous  command,  and  a  blank  line
       repeats  from the address 'next' with count 1 and no modi-
       fiers.  Specifying 'address' sets 'dot'  to  the  address.
       Omitting 'address' uses 'dot'.  A missing 'count' is taken
       to be 1  for  printing  commands  or  infinity  for  stack
       traces.