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

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

[karthikeyan.s]

Hi,
> I've had a go at implementing a backend for hardware watchpoints and breakpoints in the Kernel:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/01117
> 0.html
Thanks.

>I'm hoping to submit a newer version of this patchset against 2.6.35.
>I'll add you on CC when I post it to the list. The main changes will be:
Thanks again! Looking forward to it.

> It's worth noting that using the context-id based watchpoint will
> almost certainly break in the case of ASID rollover for a process. It
> also won't allow you to install watchpoints on a per-thread basis afaict.
Yeah I agree. Not sure about the per-thread hypothesis.

>The HW-breakpoint framework inserts/removes breakpoints on context
>switch so the need for hardware assisted context id matching is removed.
This was my next step. I thought context id based implementation would
let me get familiar with what I am doing quickly and then I can take
up context-switch-time bkpt insertion.
But you beat me to it totally!

Going through your patch and will be trying it soon. At first sight,
seems the gdb changes aren't there in that link. Can you point me to
the gdb changes?

Thanks,
Karthik

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

[Matthew Gretton-Dann]

On Tue, 2010-06-01 at 20:35 +0530, karthikeyan.s wrote:
> Hi,
> > I've had a go at implementing a backend for hardware watchpoints and breakpoints in the Kernel:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/01117
> > 0.html
> Thanks.
> 
> >I'm hoping to submit a newer version of this patchset against 2.6.35.
> >I'll add you on CC when I post it to the list. The main changes will be:
> Thanks again! Looking forward to it.
> 
> Going through your patch and will be trying it soon. At first sight,
> seems the gdb changes aren't there in that link. Can you point me to
> the gdb changes?

We don't have any gdb patches in a releasable state at this moment in
time.  When the ptrace interface settles down in the 2.6.35 Linux
kernel, and the updated kernel patch has been submitted, we will submit
patches to take advantage of hardware breakpoints to gdb.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd

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

[karthikeyan.s]

Hi Will,
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.

-Karthik

On Tue, Jun 1, 2010 at 8:48 PM, Matthew Gretton-Dann
<matthew.gretton-dann@arm.com> wrote:
> On Tue, 2010-06-01 at 20:35 +0530, karthikeyan.s wrote:
>> Hi,
>> > I've had a go at implementing a backend for hardware watchpoints and breakpoints in the Kernel:
>> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/01117
>> > 0.html
>> Thanks.
>>
>> >I'm hoping to submit a newer version of this patchset against 2.6.35.
>> >I'll add you on CC when I post it to the list. The main changes will be:
>> Thanks again! Looking forward to it.
>>
>> Going through your patch and will be trying it soon. At first sight,
>> seems the gdb changes aren't there in that link. Can you point me to
>> the gdb changes?
>
> We don't have any gdb patches in a releasable state at this moment in
> time.  When the ptrace interface settles down in the 2.6.35 Linux
> kernel, and the updated kernel patch has been submitted, we will submit
> patches to take advantage of hardware breakpoints to gdb.
>
> Thanks,
>
> Matt
>
> --
> Matthew Gretton-Dann
> Principal Engineer - PDSW Tools
> ARM Ltd
>
>



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

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

[Will Deacon]

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

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

[karthikeyan.s]

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
---

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

[Will Deacon]

H Karthik,

> 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.

Since you're trying to use this stuff, I've just submitted a new version
of the patchset:

http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017680.html

Please see if the issue occurs with the new code. Unfortunately, I've not
had a chance to test it because the ptrace interface has changed and I
don't have a GDB that can `talk the talk'.

Thanks,

Will

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

[karthikeyan.s]

Thanks. Unfortunately, we are not working on 2.6.35. Shortly (I don't
know how soon) we will. I can try this patch only then. I did go
through the patch though.

Regarding the issue I had earlier, it is a NULL pointer dereference at
__sigqueue_alloc
at.
user = get_uid(__task_cred(t)->user);

Seems to be related to the perf event patch I took from arm linux for
your patch.


On Thu, Jun 10, 2010 at 8:32 PM, Will Deacon <will.deacon@arm.com> wrote:
> H Karthik,
>
>> 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.
>
> Since you're trying to use this stuff, I've just submitted a new version
> of the patchset:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017680.html
>
> Please see if the issue occurs with the new code. Unfortunately, I've not
> had a chance to test it because the ptrace interface has changed and I
> don't have a GDB that can `talk the talk'.
>
> Thanks,
>
> Will
>
>
>



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

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

[Will Deacon]

Hi Karthik,

> I started out at implementing hardware watchpoint support for armv7 in gdb. For a start, I added the
> necessary functions in gdb for armv7 architecture. Also made the kernel changes for "context id based
> watchpoint".

I've had a go at implementing a backend for hardware watchpoints and breakpoints in the Kernel:

http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011170.html

I'm hoping to submit a newer version of this patchset against 2.6.35.
I'll add you on CC when I post it to the list. The main changes will be:

- Only allowing ptrace interaction with the framework
- Changing the ptrace API to mirror the ARMv7 architected control registers
- Updated to work with the latest HW-breakpoint framework in the Kernel

It's worth noting that using the context-id based watchpoint will almost
certainly break in the case of ASID rollover for a process. It also won't
allow you to install watchpoints on a per-thread basis afaict.

The HW-breakpoint framework inserts/removes breakpoints on context switch
so the need for hardware assisted context id matching is removed.
 
Thanks,

Will

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

[Simon Richter]

Hi,

On Fri, May 28, 2010 at 02:00:24PM +0800, xingxing pan wrote:

> Hey guys, can GDB for ARM set hard breakpoint when native debugging?

On most ARM models, hardware breakpoints are only available through the
JTAG interface.

> I found GDB for i386 use the ptrace(POKE_USER,...) to set hard
> breakpoint. But in ARM's code I can't find such similar facility.

POKE_USER is a software breakpoint -- an instruction is replaced by
something that causes an exception, which is then passed to the
application as a signal, which in turn causes the traced process to stop
and gdb to be notified.

   Simon

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

[Matthew Gretton-Dann]

Hi,

On Fri, 2010-05-28 at 14:00 +0800, xingxing pan wrote:
> Hey guys, can GDB for ARM set hard breakpoint when native debugging?
> I found GDB for i386 use the ptrace(POKE_USER,...) to set hard
> breakpoint. But in ARM's code I can't find such similar facility.

GDB does not use hardware breakpoints when debugging native ARM Linux
applications.

> Dose ARM has some hardware unit to support hard breakpoint?

Some ARM CPUs have hardware breakpoint support (for instance all current
Cortex-A processors).  However, the number of hardware breakpoints
available varies depending on the CPU.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - PDSW Tools
ARM Ltd

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

[xingxing pan]

Can anyone help?

2010/5/28 xingxing pan <forandom@gmail.com>:
> Hey guys, can GDB for ARM set hard breakpoint when native debugging?
> I found GDB for i386 use the ptrace(POKE_USER,...) to set hard
> breakpoint. But in ARM's code I can't find such similar facility.
> Dose ARM has some hardware unit to support hard breakpoint?
>

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

[xingxing pan]

Hey guys, can GDB for ARM set hard breakpoint when native debugging?
I found GDB for i386 use the ptrace(POKE_USER,...) to set hard
breakpoint. But in ARM's code I can't find such similar facility.
Dose ARM has some hardware unit to support hard breakpoint?