Summary: | Unstable GDB test results due to change in dl_debug_state() | ||
---|---|---|---|
Product: | gdb | Reporter: | Vinitha Vijayan <jiji.vinitha> |
Component: | testsuite | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | WAITING --- | ||
Severity: | normal | CC: | gbenson, jiji.vinitha, pedro |
Priority: | P2 | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Vinitha Vijayan
2012-05-07 15:00:30 UTC
Hi, Some more findings regarding the above failed testcase scenario. In FAIL cases it is observed that the single step breakpoint inserted after hitting breakpoint at dl_debug_state ( @bx lr ), is not being hit and the binary completes execution without stopping at any breakpoints. Verified the kernel code (arch/arm/kernel/ptrace.c and arch/arm/kernel/traps.c). After debugging the kernel found that in FAIL case , kernel does not enter the undefined instruction handler(do_undefinstr() in traps.c), in case of the single step breakpoint inserted at dl_main after first dl_debug_state call. GDB is writing breakpoint instruction 0xa000f7f0 to the location. When the testcase is passing, kernel enters this function. It seems there is some timing issue in SMP kernel environment. When the breakpoint at dl_debug_state and single_step breakpoint inserted after hitting that, are in same function , this testcases shows stable results. (I have tested by putting a single nop before the bx lr instruction in dl_debug_state.It works fine ). Any comments? Note that the _dl_debug_state style of interface in glibc may be about to change: http://sourceware.org/ml/libc-alpha/2012-07/msg00096.html Though from your comments it looks more like this is some generic issue with setting breakpoints on empty functions. Are you able to reproduce this with a simple testcase? I sounds like your kernel has some missing i-cache flushing issue in ptrace. This is the not the first time something like that is reported. E.g., see: http://kerneltrap.org/mailarchive/git-commits-head/2010/3/1/25453 Make sure you have that patch in your kernel. There may have been other similar fixes since then, and perhaps others are still necessary. |