Re: [HELP]Can GDB for ARM set hard breakpoint when native debugging?

["karthikeyan.s" <informkarthik@gmail.com>]

Hi Will,
Did you have issue any issues(kernel crash) with the watch_thread_num
test gdb test (testsuite) with your gdb changes (And offcourse with
you kernel backend!)? ( watch_thread_num is in
gdb/testsuite/gdb.base). The issue is not just with watchpoints but
also breakpoints. I am using a 2.6.33 kernel for which you had posted
the patch version2.

I tried something similar to watch_thread_num using breakpoints and I
get a hang.
#./gdb watch_thread_vum
# b main
# run
At this point the porogram is waiting in main
# hb 60
# c
Line 60 is --> shared_var++
# c (hit continue for some time)
# quit
When I quit, the kernel hangs (ping does not work).

This issue does not happen if I set the breakpoint (hb 60) after all
the threads have spawned.

I noted that gdb requests breakpoint removal and then insertion
whenever a thread is spawned. I insert breakpoints on all the current
threads (ALL_LWPS). And remove only on those threads that I inserted
the breakpoint on.

I am yet to dig in though.

Thanks,
Karthik

On Thu, Jun 3, 2010 at 5:23 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Karthik,
>
>> Just in case you are going to re-use most of the code for 2.6.35.
>> In hw_breakpoint.c, the handlers do not release the locks on wtpt/bkpt
>> not matched.
>> Should rather be:
>>  if (val != (unpredictable & ~0x3)) {
>>     rcu_read_unlock();
>>     continue;
>> }
>>
>> Otherwise I get a "schedule while atomic" bug.
>
> Well spotted! My current tree is a little different, but I've
> updated it as necessary.
>
> Thanks,
>
> Will
>
>
>



-- 
---
S. Karthikeyan | +919980814745
---