Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!cmcl2!csd2!berke From: berke@csd2.UUCP (Wayne Berke) Newsgroups: net.unix-wizards Subject: for adb hackers only Message-ID: <4060004@csd2.UUCP> Date: Fri, 25-Apr-86 17:11:00 EDT Article-I.D.: csd2.4060004 Posted: Fri Apr 25 17:11:00 1986 Date-Received: Sun, 27-Apr-86 07:24:50 EDT Organization: New York University Lines: 48 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: ,:b $c and have adb print out a stack trace the first times the process gets to . 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 . 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?