n, s, S, and B subcommand

The n, s, S and B subcommands provide step functions.

Note: These subcommands are only available within the KDB kernel debugger. They are not included in the kdb command.

Format

n [count]

s [count]

S [count]

B [count]

Parameters

Item Description
count Specifies the number of times the subcommand runs.
n Runs the number of instructions specified by count, but it treats subroutine calls as a single instruction. If specified without a number, it runs one instruction.
s Runs the number of instructions specified by the count parameter.
S Runs instructions until it encounters a bl or br branch instruction. If the count parameter is used, the number specifies how many bl and br instructions are reached before the KDB Kernel Debugger stops.
B Runs instructions until it encounters any branch instruction. If the count parameter is used, the number specifies how many branch instructions are reached before the KDB Kernel Debugger stops.

On POWER processor-based machines, steps are implemented with the SE bit of the msr status register of the processor. This bit is automatically associated with the thread or process context. The thread or process context can migrate from one processor to another.

You can interrupt any of these subcommands by pressing the Del key. Every time the KDB kernel debugger takes a step, it checks to see whether the Del key was pressed. This allows you to break into the KDB kernel debugger if the call is taking an inordinate amount of time.

If no intervening subcommands are run, any of the step commands can be repeated by pressing the Enter key.

Be aware that when you use these subcommands, an exception to the processor is made for each of the debugged program's instruction. One side-effect of exceptions is that it breaks reservations. The stcwx instruction cannot succeed if any breakpoint occurred after the last larwx instruction. The net effect is that you cannot use these subcommands with lock and atomic routines. If you do, you loop in the lock routine.

Some instructions are broken by exceptions. For example, rfi moves to and from srr0 srr1. The KDB kernel debugger tries to prevent this by printing a warning message.

When you want to take control of a sleeping thread, switch to the sleeping thread with the sw subcommand and type the s subcommand. The step is set inside the thread context, and when the thread runs again, the step breakpoint occurs.

Other

The aliases are:

  • nnexti
  • sstepi

There are no aliases for the following:

  • S
  • B

Examples

The following is an example of how to use the n, s, and B subcommands:

   KDB(1)> b .vno_close+00005C  //enable break point on vno_close+00005C
   vno_close+00005C (sid:00000000) permanent & global
   KDB(1)> e  //exit debugger
   Breakpoint
   .vno_close+00005C     lwz    r11,30(r4)          r11=0,30(r4)=xix_vops+000030
   KDB(1)> s 10  //single step 10 instructions
   .vno_close+000060     lwz    r5,68(stkp)         r5=FFD00000,68(stkp)=2FF97DD0
   .vno_close+000064     lwz    r4,0(r5)            r4=xix_vops,0(r5)=file+0000C0
   .vno_close+000068     lwz    r5,14(r5)           r5=file+0000C0,14(r5)=file+0000D4
   .vno_close+00006C      bl    <._ptrgl>           r3=05AB620C
   ._ptrgl+000000     lwz    r0,0(r11)           r0=.closef+0000F4,0(r11)=xix_close
   ._ptrgl+000004     stw    toc,14(stkp)        toc=TOC,14(stkp)=2FF97D7C
   ._ptrgl+000008   mtctr    r0                  <.xix_close+000000>
   ._ptrgl+00000C     lwz    toc,4(r11)          toc=TOC,4(r11)=xix_close+000004
   ._ptrgl+000010     lwz    r11,8(r11)          r11=xix_close,8(r11)=xix_close+000008
   ._ptrgl+000014   bcctr                        <.xix_close>
   KDB(1)> <CR/LF>  //repeat last single step command
   .xix_close+000000    mflr    r0                  <.vno_close+000070>
   .xix_close+000004     stw    r31,FFFFFFFC(stkp)  r31=_vno_fops$$,FFFFFFFC(stkp)=2FF97D64
   .xix_close+000008     stw    r0,8(stkp)          r0=.vno_close+000070,8(stkp)=2FF97D70
   .xix_close+00000C    stwu    stkp,FFFFFFA0(stkp) stkp=2FF97D68,FFFFFFA0(stkp)=2FF97D08
   .xix_close+000010     lwz    r31,12B8(toc)       r31=_vno_fops$$,12B8(toc)=_xix_close$$
   .xix_close+000014     stw    r3,78(stkp)         r3=05AB620C,78(stkp)=2FF97D80
   .xix_close+000018     stw    r4,7C(stkp)         r4=00000020,7C(stkp)=2FF97D84
   .xix_close+00001C     lwz    r3,12BC(toc)        r3=05AB620C,12BC(toc)=xclosedbg
   .xix_close+000020     lwz    r3,0(r3)            r3=xclosedbg,0(r3)=xclosedbg
   .xix_close+000024     lwz    r4,12C0(toc)        r4=00000020,12C0(toc)=pfsdbg
   KDB(1)> r  //return to the end of function
   .vno_close+000070     lwz    toc,14(stkp)        toc=TOC,14(stkp)=2FF97D7C
   KDB(1)> S 4  //return to the end of function
   .vno_close+000088      bl    <._ptrgl>           r3=05AB620C
   .xix_rele+00010C      bl    <.vn_free>          r3=05AB620C
   .vn_free+000140      bl    <.gpai_free>        r3=gpa_vnode
   .gpai_free+00002C      br                        <.vn_free+000144>
   KDB(1)> <CR/LF>  //repeat last command
   .vn_free+00015C      br                        <.xix_rele+000110>
   .xix_rele+000118      bl    <.iput>             r3=058F9360
   .iput+0000A4      bl    <.iclose>           r3=058F9360
   .iclose+000148      br                        <.iput+0000A8>
   KDB(1)> <CR/LF>  //repeat last command
   .iput+0001A4      bl    <.insque2>          r3=058F9360
   .insque2+00004C      br                        <.iput+0001A8>
   .iput+0001D0      br                        <.xix_rele+00011C>
   .xix_rele+000164      br                        <.vno_close+00008C>
   KDB(1)> r  //return to the end of function
   .vno_close+00008C     lwz    toc,14(stkp)        toc=TOC,14(stkp)=2FF97D7C
   KDB(1)>