A MDB tip on stack backtrace

When you set a breakpoint to a function entry point in MDB, and try to show the stack backtrace through dcmd, you may find it not always corrent. Now let me show you a small tip.

You may want to set a breakpoint like this:

# mdb -K
kmdb: target stopped at:
kmdbmod`kaif_enter+7:   popfl
[1]> tcp_zcopy_check:b

When the kernel hits this function, you'll check the stack backtrace as follows:

kmdb: stop at ip`tcp_zcopy_check
kmdb: target stopped at:
ip`tcp_zcopy_check:     pushl  %ebp
[1]> $c
ip`tcp_zcopy_check(cc6eb4a0, 2, ffff, 800, 4, cdce8edc)
ip`svr4_optcom_req+0x64e(cc6eb4a0, cd88afc0, cbeca010, fecc4048)
ip`tcp_wput_proto+0x179(cc059e00, cd88afc0, c1942e00)
ip`squeue_enter+0x335(c1942e00, cd88afc0, f68ab44c, cc059e00, 1c)
ip`tcp_wput+0x244(cc6eb4a0, cd88afc0)
putnext+0x298(cc6eb4a0, cd88afc0)
strput+0x19c(cc6e5d00, cd88afc0, 0, c2336b94, 0, 0)
kstrputmsg+0x219(cde5f940, 0, 0, ffffffff, 0, 2c4)
sockfs`sotpi_setsockopt+0x5c6(cc4334f8, ffff, 800, c2336c98, 4)
sockfs`sosendfile64+0x1e6(cc4d57e8, cc4d5200, c2336cd0, c2336e24)
sendvec64+0xfb(cc4d57e8, 8047d98, 1, 8047dac, 4)
sendfilev+0x163()
sys_call+0x1a2()

I don't think the stack backtrace is correct because tcp_zcopy_check has only one argument and svr4_optcom_req never calls him!

Now let's check the function entry point, you'll see almost every function on x86 begins with the following instructions:

[1]> tcp_zcopy_check::dis
ip`tcp_zcopy_check:             pushl  %ebp
ip`tcp_zcopy_check+1:           movl   %esp,%ebp
ip`tcp_zcopy_check+3:           subl   $0x8,%esp
[...]

That's the homework for every function, after executing the above instrctions, the esp and ebp pointer will point to the right place in the current stack frame, then you'll see the corrent stack backtrace.

[1]> ::step over
kmdb: target stopped at:
ip`tcp_zcopy_check+1:   movl   %esp,%ebp
[1]> ::step over
kmdb: target stopped at:
ip`tcp_zcopy_check+3:   subl   $0x8,%esp
[1]> ::step over
kmdb: target stopped at:
ip`tcp_zcopy_check+6:   pushl  %ebx
[1]> $c
ip`tcp_zcopy_check+6(cc05a1c0)
ip`tcp_opt_set+0x276(cc6eb4a0, 2, ffff, 800, 4, cdce8edc)
ip`svr4_optcom_req+0x64e(cc6eb4a0, cd88afc0, cbeca010, fecc4048)
ip`tcp_wput_proto+0x179(cc059e00, cd88afc0, c1942e00)
ip`squeue_enter+0x335(c1942e00, cd88afc0, f68ab44c, cc059e00, 1c)
ip`tcp_wput+0x244(cc6eb4a0, cd88afc0)
putnext+0x298(cc6eb4a0, cd88afc0)
strput+0x19c(cc6e5d00, cd88afc0, 0, c2336b94, 0, 0)
kstrputmsg+0x219(cde5f940, 0, 0, ffffffff, 0, 2c4)
sockfs`sotpi_setsockopt+0x5c6(cc4334f8, ffff, 800, c2336c98, 4)
sockfs`sosendfile64+0x1e6(cc4d57e8, cc4d5200, c2336cd0, c2336e24)
sendvec64+0xfb(cc4d57e8, 8047d98, 1, 8047dac, 4)
sendfilev+0x163()
sys_call+0x1a2()

Now the backtrace is correct!

So the conclusion is: Try one more instruction, and think more about what you have seen, there will be a reasonbale fact behind that.