[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]
Kernel Extensions and Device Support Programming Concepts

Breakpoints/Steps Subcommands for the KDB Kernel Debugger and kdb Command


b Subcommand

Note: This subcommand is only available within the kdb command; it is not included in the KDB Kernel Debugger.

The b subcommand sets permanent global break point in the code. With trace break points, there is a maximum of 32 break points. KDB checks that a valid instruction will be trapped and prints a warning message. If it does, the breakpoint should be removed, else memory can be corrupted (the break point has been installed).

It is possible to specify if the address is physical or virtual with -p or -v option. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM inititialisation, the address is physical (real address), else virtual (effective address). After VMM is setup, to set break-point in real-mode code that is not mapped V=R, -p must be used, else KDB expects a virtual address and translates the address.

Example before VMM setup

   KDB(0)> b vsi set break point on vsi()
   .vsi+000000 (real address:002AA5A4) permanent & global
   KDB(0)> e exit debugger
   ...
   Breakpoint
   .vsi+000000     stmw    r29,FFFFFFF4(stkp)  <.mainstk+001EFC> r29=isync_sc1+000040,FFFFFFF4(stkp)=.mainstk+001EFC

Example after VMM setup

   KDB(0)> b display current active break points
   No breakpoints are set.
   KDB(0)> b 0 set break point at address 0
   WARNING: break point at 00000000 on invalid instruction (00000000)
   00000000 (sid:00000000) permanent & global
   KDB(0)> c 0 remove break point at address 0
   KDB(0)> b vmvcs set break point on vmvcs()
   .vmvcs+000000 (sid:00000000) permanent & global
   KDB(0)> b i_disable set break point on i_disable()
   .i_disable+000000 (sid:00000000) permanent & global
   KDB(0)> e exit debugger
   ...
   Breakpoint
   .i_disable+000000   mfmsr    r7                  <start+001008> r7=DEADBEEF
   KDB(0)> b display current active break points
   0:      .vmvcs+000000 (sid:00000000)  permanent & global
   1:      .i_disable+000000 (sid:00000000)  permanent & global
   KDB(0)> c 1 remove break point slot 1
   KDB(0)> b display current active break points
   0:      .vmvcs+000000 (sid:00000000)  permanent & global
   KDB(0)> e exit debugger
   ...
   Breakpoint
   .vmvcs+000000    mflr    r10                 <.initcom+000120>
   KDB(0)> ca remove all break points

lb Subcommand

Note: This subcommand is only available within the kdb command; it is not included in the KDB Kernel Debugger.

The local break point subcommand sets permanent local break point in the code, according to the corresponding toggle (cpu or thread based). One context is associated to the local break point. Up to 8 different contexts are setable for each local break point. The context is the effective address of the thread entry, or the processor number. In the following example, we show that context is the effective address of the curthread. Local break points are cleared context by context with the lc subcommand. By default the current context is cleared. The c or ca subcommand clears all contexts.

When the break point is hit with another context, KDB prints a warning. Using switch subcommand, it is possible to select another context, instead ofthe current one. After switching from the current context (thread or processor) to another one, the lb subcommand will apply on this new context.

It is possible to specify if the address is physical or virtual with -p or -v option. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM inititialisation, the address is physical (real address), else virtual (effective address). After VMM is setup, to set break-point in real-mode code that is not mapped V=R, -p must b used, else KDB expects a virtual address and translates the address.

Example

   KDB(0)> b execv set break point on execv()
   Assumed to be [External data]: 001F4200 execve
   Ambiguous: [Ext func]
   001F4200 .execve
   .execve+000000 (sid:00000000) permanent & global
   KDB(0)> e exit debugger
   ...
   Breakpoint
   .execve+000000    mflr    r0                  <.svc_flih+00011C>
   KDB(0)> ppda print current processor data area

   Per Processor Data Area [00086E40]

   csa......................2FEE0000  mstack...................0037CDB0
   fpowner..................00000000  curthread................E60008C0
   ...
   KDB(0)> lb kexit set local break point on kexit()
   .kexit+000000 (sid:00000000) permanent & local < ctx: thread+0008C0 >
   KDB(0)> b display current active break points
   0:      .execve+000000 (sid:00000000)  permanent & global
   1:      .kexit+000000 (sid:00000000)  permanent & local < ctx: thread+0008C0 >
   KDB(0)> e exit debugger
   ...
   Warning, breakpoint ignored (context mismatched):
   .kexit+000000    mflr    r0                  <._exit+000020>
   Breakpoint
   .kexit+000000    mflr    r0                  <._exit+000020>
   KDB(0)> ppda print current processor data area

   Per Processor Data Area [00086E40]

   csa......................2FEE0000  mstack...................0037CDB0
   fpowner..................00000000  curthread................E60008C0
   ...
   KDB(0)> lc 1 thread+0008C0 remove local break point slot 1

c, lc, and ca Subcommands

Note: This subcommand is only available within the kdb command; it is not included in the KDB Kernel Debugger.

To clear break point, use one of these subcommands. cat subcommand erases all of them: global, local, permanent or not. c and lc subcommand erase only the specified break point (by slot number, symbol or address). With lc subcommand, by default first context is removed. If there are more t one context, it is possible to specify the context to be removed.

It is possible to specify if the address is physical or virtual with -p or -v option. By default KDB chooses the current state of th machine: if the subcommand is entered before VMM inititialisation, the address is physical (real address), else virtual (effective address). After VMM is setup, to set break-point in real-mode code that is not mapped V=R, -p must be used, else KDB expects a virtual address and translates the address.

WARNING: Slot numbers are not fixed. To clear slot 1 and slot 2 enter ct 2; ct 1 or ct 1; ct 1, do not enter ct 1; ct 2

Example





r and gt Subcommands

Note: This subcommand is only available within the kdb command; it is not included in the KDB Kernel Debugger.

Non permanent break point can be set by the go to address subcommands. In that case it is local break points, and when KDB is entered, this break point is cleared. The r subcommand sets a break point on the address found in the lr register. In SMP environnement, it is possible to hit this break point on another processor, so it is important to have thread/process local break point.

The gt subcommand has the same effect but we precise the wanted address.

It is possible to specify if the address is physical or virtual with -p or -v option. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM inititialisation, the address is physical (real address), else virtual (effective address). After VMM is setup, to set break-point in real-mode code that is not mapped V=R, -p must be used, else KDB expects a virtual address and translates the address.

When the break point is hit with another context, KDB prints a warning.

Example

   KDB(2)> b _iput enable break point on _iput()
   ._iput+000000 (sid:00000000) permanent & global
   KDB(2)> e exit debugger
   ...
   Breakpoint
   ._iput+000000     stmw    r29,FFFFFFF4(stkp)  <2FF3B1CC> r29=0A4C6C20,FFFFFFF4(stkp)=2FF3B1CC
   KDB(6)> f
   thread+014580 STACK:
   [0021632C]_iput+000000 (0A4C6C20, 0571A808 [??])
   [00263EF4]jfs_rele+0000B4 (??)
   [00220B58]vnop_rele+000018 (??)
   [00232178]vno_close+000058 (??)
   [002266C8]closef+0000C8 (??)
   [0020C548]closefd+0000BC (??, ??)
   [0020C70C]close+000174 (??)
   [000037C4].sys_call+000000 ()
   [D000715C]fclose+00006C (??)
   [10000580]10000580+000000 ()
   [10000174]__start+00004C ()
   KDB(6)> r go to the end of the function
   ...
   .jfs_rele+0000B8        b    <.jfs_rele+00007C>  r3=0
   KDB(7)> e exit debugger
   ...
   Breakpoint
   ._iput+000000     stmw    r29,FFFFFFF4(stkp)  <2FF3B24C> r29=09D75BD0,FFFFFFF4(stkp)=2FF3B24C
   KDB(3)> gt @lr go to the link register value
   .jfs_rele+0000B8 (sid:00000000) step < ctx: thread+001680 >
   ...
   .jfs_rele+0000B8        b    <.jfs_rele+00007C>  r3=0
   KDB(1)>

n s, S, and B Subcommands

Note: This subcommand is only available within the kdb command; it is not included in the KDB Kernel Debugger.

Step can be done by two subcommands. The s subcommand allows the processor to single step on the next instruction. The n subcommand causes step to skip over subroutine calls, and we can follow the main flow of control. A count may specify how many steps are executed before returning to KDB dialog. Enter CR/LF and KDB continues the last step subcommand.

The S subcommand single steps but stops only on bl and br instructions. With that, we can see every call and return of routines. A count is also used to specify how many times KDB continues before stopping, and CR/LF continues the last subcommand

On POWER RS1 machine, steps are implemented with non permanent local break points. On POWER PC machine, steps are implemented with the SE bit of the msr status register of the processor. This bit is automatically associated with the thread/process context and can migrate from one processor to another.

A too long step subcommand can be interrupted by typing DEL key. Every time KDB treats a step occurence, DEL key is tested.

Be aware that when you single step a program, this makes an exception to the processor for each of the debugged program's instruction. One side-effect of exceptions is to break reservations (see POWER PC architecture). This is why stcwx will *never* succeed if any breakpoint occurred since the last larwx. The net effect is that lock and atomic routines are NOT STEPPABLE. If you do it anyway, the system won't break, but you will loop in the lock routine. If that happens, you may just "return" from the lock routine to the caller, and if the lock is free, you will get it!

Be aware also that some instructions are broken by exceptions. For examples, rfi, move to-from srr0 srr1. KDB tries to prevent against that by printing a warning message.

Note that the S subcommand of KDB (which single-steps the program until the next sub-routine call/return) will silently and endlessly fail to go through the atomic/lock routines. To watch out for this, you will get the KDB prompt again with a warning message.

When you want to take control of a thread currently sleeping, it is possible to step in the context of this thread. To do that you just have to switch to the sleeping thread (with sw subcommand) and to type the s subcommand. The step is set inside the thread context, and when the thread runs again, the step break point occurs.

Example

   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 
   .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)>

[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]