post handler in kprobe would miss

[georgekang]

Sometimes, the stack[REG_PC](in kernel/kprobes.c) was nvic_handler52, rather than not the next instruction of breakpoint. The is because the priority of UART is higher than ktimer_handler, the location of breakpoint.

[georgekang]

When setting breakpoint at instruction in user text, this issue also happens.
It can not be solved by previous workaround because user text runs at
thread mode. The behavior of breakpoint should be re-implemented.

[arcbbb]

Hi @georgekang , thanks for your noticing.
I was considering if the above patch can serve your purpose.
Appreciate your kindly help.

[georgekang]

Hi @arcbbb , thanks for your help.
However, the above patch can not solve this issue.
You can try following patch to observe this issue.

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 66ce04f..64d43a8 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -6,6 +6,7 @@
 #include <kprobes.h>
 #include <platform/armv7m.h>
 #include <init_hook.h>
+#include <debug.h>

 static struct kprobe *kp_list;

@@ -129,8 +130,13 @@ void kprobe_postbreak(uint32_t *stack, uint32_t *kp_regs)
 {
        struct kprobe *kp = kp_list;
        while (kp != NULL) {
-               if ((uint32_t) kp->step_addr == stack[REG_PC] && kp->post_handler)
-                       kp->post_handler(kp, stack, kp_regs);
+               if ((uint32_t) kp->step_addr == stack[REG_PC]){
+                       if( kp->post_handler)
+                               kp->post_handler(kp, stack, kp_regs);
+               }else{
+                       dbg_printf(DL_KDB, "0x%x <-> 0x%x\n", kp->step_addr, stack[REG_PC]);
+               }
+                      
                kp = kp->next;
        }

[georgekang]

When sampling is enabled, you can sometimes get following result.
Because there is only one breakpoint in system, it is impossible
to show "0x8002d16 <-> 0x8001824".

## KDB ##
-------TOP------
 2428 [ L4_Ipc                   ]
 1593 [ softirq_execute          ]
  834 [ __svc_handler            ]
  708 [ schedule_select          ]
  423 [ syscall_handler          ]
  228 [ kernel_thread            ]
  220 [ do_ipc                   ]
  209 [ softirq_schedule         ]
   98 [ thread_isrunnable        ]
   91 [ thread_current           ]
   34 [ sys_ipc                  ]
   26 [ thread_map_search        ]
   22 [ dbg_printf               ]
   20 [ pendsv_handler           ]
   20 [ ktimer_enter_tickless    ]
   15 [ svc_handler              ]
   13 [ dbg_vprintf              ]
   12 [ atomic_get               ]
    8 [ thread_by_globalid       ]
    7 [ sched_slot_dispatch      ]
    7 [ atomic_set               ]
    6 [ set_kernel_state         ]
    3 [ __pong_thread            ]
    1 [ ipc_read_mr              ]
    1 [ ipc_write_mr             ]
----------------
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824
0x8002d16 <-> 0x8001824

08001824 <nvic_handler52>:↵
 8001824:»··b500      »·push»···{lr}↵
 8001826:»··f7ff ffa3 »·bl»·8001770 <__uart_irq_handler>↵
 800182a:»··f64e 5304 »·movw»···r3, #60676»·; 0xed04↵
 800182e:»··f2ce 0300 »·movt»···r3, #57344»·; 0xe000↵
 8001832:»··681a      »·ldr»r2, [r3, #0]↵
...

08002d14 <ktimer_handler>:↵
 8002d14:»··b500      »·push»···{lr}↵
 8002d16:»··f7ff ffb5 »·bl»·8002c84 <__ktimer_handler>↵
 8002d1a:»··f64e 5304 »·movw»···r3, #60676»·; 0xed04↵
 8002d1e:»··f2ce 0300 »·movt»···r3, #57344»·; 0xe000↵

[arcbbb]

Thank your patch. I see the problem that single-step brings.
Let's think another way to do this.