for adb hackers only

[Wayne Berke]

One of the valuable features of adb is the ability to associate
count values with breakpoints.  Instead of stopping each time
we come to a certain spot, we can execute an arbitrary command
(e.g. print out a memory location or register).  Unfortunately,
certain commands do not work in this way.  Most notably, try doing a stack
trace each time we come to a certain place.  The debugger will
ignore the count value and stop after hitting the breakpoint once.
If you examine the code in runpcs(), you can see that the problem
arises because of the return value from command() which, if non-zero,
causes adb to decrement the count and return to the debugger only when
the count becomes 0 -- on the other hand, if command() returns zero,
we immediately return to the main interpretive loop.  The exact code
(taken from the 4.2 VAX version, all Bourneisms intact) is:

	IF bkpt->flag==BKPTEXEC
	ORF ((bkpt->flag=BKPTEXEC)
		ANDF bkpt->comm[0]!=EOR
		ANDF command(bkpt->comm,':')
		ANDF --bkpt->count)
	THEN execbkpt(bkpt,execsig); execsig=0; loopcnt++;
	ELSE bkpt->count=bkpt->initcnt; rc=1;
	FI

Note that it is the loopcnt++ instruction which results delaying the
return to the debugger.

Now if I am using adb and want to print out a stack trace each time
I encounter a specific breakpoint, I would want to say:

	<text_address>,<count_value>:b $c

and have adb print out a stack trace the first <count_value> times
the process gets to <text_address>.  However, the return statement from
command() is:

	return(adrflg ANDF dot != 0);

and adrflg==0 for commands like $c and $r.  This results in adb performing
a single stack trace regardless of the specified <count_value>.

Since this return value is only used in the first code segment, I
see no reason to change the return statement to:

	return(dot != 0)

Does anyone know why the original return value depended on adrflg, or is it
just a bug?