The b subcommand sets a permanent global breakpoint in the code. KDB checks that a valid instruction will be trapped. If an invalid instruction is detected a warning message is displayed. If the warning message is displayed the breakpoint should be removed; otherwise, memory can be corrupted.
b [-p | -v] [Address]
Aliases: brk
It is possible to specify whether the address is physical or virtual with -p and -v options. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM initialization, the address is physical (real address), else virtual (effective address). After VMM is setup, the -p flag must be used to set breakpoints in real-mode code that is not mapped V=R, otherwise KDB expects a virtual address and translates the address.
If no arguments are supplied to the b subcommand all of the current break and trace points are displayed.
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
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
The local breakpoint lb subcommand sets a permanent local breakpoint in the code for a specific context. The context can either be CPU or thread based. Whether CPU or thread based context is to be used is controllable through a set option. Each lb subcommand executed associates one context with the local breakpoint. Up to 8 different contexts are setable for each local breakpoint. The context is the effective address of the current thread entry in the thread table or the current processor number.
lb [-p | -v] [Address]
Aliases: lbrk
If the lb subcommand is entered with no arguments, all current trace and break points are displayed.
If an address is specified, the break is set with the context of the current thread or CPU. To set a break using a context other than the current thread or CPU, the current context can be changed using the switch and cpu subcommands.
If a local breakpoint is hit with a context that has not been specified, a message is displayed, but a break does not occur.
It is possible to specify whether the address is physical or virtual with the -p and -v options. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM initialization, the address is physical (real address), else virtual (effective address). After VMM is setup, the -p must be used to set a breakpoint in real-mode code that is not mapped V=R, otherwise KDB expects a virtual address and translates the address.
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
A non-permanent breakpoint can be set using the r and gt subcommands. These subcommands set local breakpoints which are cleared after they have been hit. The r subcommand sets a breakpoint on the address found in the lr register. In SMP environment, it is possible to hit this breakpoint on another processor, so it is important to have thread/process local break point.
The gt subcommand performs the same as the r subcommand except that the breakpoint address must be specified.
r
gt [-p | -v] [Address]
It is possible to specify whether the address is physical or virtual with the -p and -v options. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM initialization, the address is physical (real address), else virtual (effective address). After VMM is initialized, the -p flag must be used to set a breakpoint in real-mode code that is not mapped V=R, otherwise KDB expects a virtual address and translates the address.
Aliases: r - return
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)>
Breakpoints are cleared using one of the following subcommands: c, lc, or ca. The ca subcommand erases all breakpoints. The c and lc subcommands erase only the specified breakpoint. The c subcommand clears all contexts for a specified breakpoint. The lc subcommand can be used to clear a single context for a breakpoint. If a specific context is not specified, the current context is used to determine which local breakpoint context to remove.
c [slot | [-p | -v] Address]
lc [slot | [-p | -v] Address [ctx]]
ca
Aliases:
It is possible to specify whether the address is physical or virtual with the -p and -v options. By default KDB chooses the current state of the machine: if the subcommand is entered before VMM initialization, the address is physical (real address), if the subcommand is entered after VMM initialization, the address is virtual (effective address).
KDB(1)> b list breakpoints 0: .halt_display+000000 (sid:00000000) permanent & global 1: .v_exception+000000 (sid:00000000) permanent & global 2: .v_loghalt+000000 (sid:00000000) permanent & global 3: .p_slih+000000 (sid:00000000) trace {hit: 0} KDB(1)> c 2 clear breakpoint slot 2 0: .halt_display+000000 (sid:00000000) permanent & global 1: .v_exception+000000 (sid:00000000) permanent & global 2: .p_slih+000000 (sid:00000000) trace {hit: 0} KDB(1)> c v_exception clear breakpoint set on v_exception 0: .halt_display+000000 (sid:00000000) permanent & global 1: .p_slih+000000 (sid:00000000) trace {hit: 0} KDB(1)> ca clear all breakpoints 0: .p_slih+000000 (sid:00000000) trace {hit: 0}
The n and s subcommands provide step functions. The s subcommand allows the processor to single step to the next instruction. The n subcommand also single steps, but it steps over subroutine calls as though they were a single instruction. A count can specify how many steps are executed before returning to the KDB prompt.
The S subcommand single steps but stops only on bl and br instructions. With that, you can see every call and return of routines. A count can also be used to specify how many times KDB continues before stopping.
The B subcommand steps stopping at each branch instruction.
n [count]
s [count]
S [count]
B [count]
Aliases:
On POWER RS1 machine, steps are implemented with non-permanent local breakpoints. On POWER-based machine, 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 and can migrate from one processor to another.
A step subcommand can be interrupted by typing the DEL key. Every time KDB executes a step the DEL key is tested. This allows breaking into the debugger if a step command is stepping over routine calls, but the call is taking an inordinate amount of time.
If no intervening subcommands have been executed, any of the step commands can be repeated by using the Enter key.
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. 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 stepable. If you do it anyway, you will loop in the lock routine. If that happens, you may "return" from the lock routine to the caller, and if the lock is free, you will get it.
Some instructions are broken by exceptions. For example, rfi, moves to and from srr0 srr1. KDB tries to prevent against this by printing a warning message.
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 sleeping thread, it is possible to step in the context of this thread. To do that, switch to the sleeping thread (with 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.
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)>