Using hardware watchpoint for applications debugging

Using hardware watchpoint for applications debugging

[colin]

Hi all,
Our applications encounter memory crash very often. Thus we would like to
use hardware watchpoint on our platform, MIPS 4KEc.
After starting to design it, more and more issues emerge. They are listed
below:
    1. WatchLo Register only has 29 bits to indicate the VAddr. Therefore,
it will also trigger exceptions when accessing nearby addresses.
    2. When an exception happens and we find that it's not touching the righ
address, we will discard it. However, exception will happen again because
the former instruction will be re-executed when the exception is finished.

Is there any easy way to solve these problems?

Regards,
Colin

Using hardware watchpoint for applications debugging

[colin]

Hi all,
Our applications encounter memory crash very often. Thus we would like to
use hardware watchpoint on our platform, MIPS 4KEc.
After starting to design it, more and more issues emerge. They are listed
below:
    1. WatchLo Register only has 29 bits to indicate the VAddr. Therefore,
it will also trigger exceptions when accessing nearby addresses.
    2. When an exception happens and we find that it's not touching the righ
address, we will discard it. However, exception will happen again because
the former instruction will be re-executed when the exception is finished.

Is there any easy way to solve these problems?

Regards,
Colin

Re: Using hardware watchpoint for applications debugging

[Nigel Stephens]

colin wrote:.
>     2. When an exception happens and we find that it's not touching the righ
> address, we will discard it. However, exception will happen again because
> the former instruction will be re-executed when the exception is finished.
>
>   

You'll need to single-step over the instruction which generated the
unwanted watchpoint exception, with the watchpoint disabled. Then after
handling the single step reenable the watchpoint and resume normal
execution.

It would be best if you added watchpoint support to the kernel ptrace
code: since that would make the watchpoints usable by GDB also.

Nigel

Re: Using hardware watchpoint for applications debugging

[Kevin D. Kissell]

> colin wrote:.
> >     2. When an exception happens and we find that it's not touching the righ
> > address, we will discard it. However, exception will happen again because
> > the former instruction will be re-executed when the exception is finished.
> >
> 
> You'll need to single-step over the instruction which generated the
> unwanted watchpoint exception, with the watchpoint disabled. Then after
> handling the single step reenable the watchpoint and resume normal
> execution.

There's actually a simpler and more efficient approach in Linux.  The code 
already exists in the MIPS Linux kernel to "skip" the instruction responsible 
for the current exception, because the situation also arises for emulated 
instructions.   In do_watch(), in the cases where you want to ignore the
watchpoint, you should be able to just invoke compute_return_epc(regs)
and return.  There should be no need to handle single-step exceptions 
or disable/reenable the watchpoint.

            Regards,

            Kevin K.

Re: Using hardware watchpoint for applications debugging

[Kevin D. Kissell]

> colin wrote:.
> >     2. When an exception happens and we find that it's not touching the righ
> > address, we will discard it. However, exception will happen again because
> > the former instruction will be re-executed when the exception is finished.
> >
> 
> You'll need to single-step over the instruction which generated the
> unwanted watchpoint exception, with the watchpoint disabled. Then after
> handling the single step reenable the watchpoint and resume normal
> execution.

There's actually a simpler and more efficient approach in Linux.  The code 
already exists in the MIPS Linux kernel to "skip" the instruction responsible 
for the current exception, because the situation also arises for emulated 
instructions.   In do_watch(), in the cases where you want to ignore the
watchpoint, you should be able to just invoke compute_return_epc(regs)
and return.  There should be no need to handle single-step exceptions 
or disable/reenable the watchpoint.

            Regards,

            Kevin K.

Re: Using hardware watchpoint for applications debugging

[colin]

Hi Nigel,
We use the same way with you to handle the issue 2.

As to adding watchpoint to kernel, there will be another problem.
ASID in kernel is variable. Therefore, we cannot indicate which thread we
want to watch by ASID.
What we can do is setting G (global) bit to WatchHi Register and then all
threads accessing that address will cause the exception.
In the exception, it will filter the threads by PID to find out the thread
we are watching.

Regards,
Colin

----- Original Message ----- 
From: "Nigel Stephens" <nigel@mips.com>
To: "colin" <colin@realtek.com.tw>
Cc: <linux-mips@linux-mips.org>
Sent: Wednesday, March 29, 2006 10:08 PM
Subject: Re: Using hardware watchpoint for applications debugging


>
>
> colin wrote:.
> >     2. When an exception happens and we find that it's not touching the
righ
> > address, we will discard it. However, exception will happen again
because
> > the former instruction will be re-executed when the exception is
finished.
> >
> >
>
> You'll need to single-step over the instruction which generated the
> unwanted watchpoint exception, with the watchpoint disabled. Then after
> handling the single step reenable the watchpoint and resume normal
> execution.
>
> It would be best if you added watchpoint support to the kernel ptrace
> code: since that would make the watchpoints usable by GDB also.
>
> Nigel
>

Re: Using hardware watchpoint for applications debugging

[colin]

Hi Nigel,
We use the same way with you to handle the issue 2.

As to adding watchpoint to kernel, there will be another problem.
ASID in kernel is variable. Therefore, we cannot indicate which thread we
want to watch by ASID.
What we can do is setting G (global) bit to WatchHi Register and then all
threads accessing that address will cause the exception.
In the exception, it will filter the threads by PID to find out the thread
we are watching.

Regards,
Colin

----- Original Message ----- 
From: "Nigel Stephens" <nigel@mips.com>
To: "colin" <colin@realtek.com.tw>
Cc: <linux-mips@linux-mips.org>
Sent: Wednesday, March 29, 2006 10:08 PM
Subject: Re: Using hardware watchpoint for applications debugging


>
>
> colin wrote:.
> >     2. When an exception happens and we find that it's not touching the
righ
> > address, we will discard it. However, exception will happen again
because
> > the former instruction will be re-executed when the exception is
finished.
> >
> >
>
> You'll need to single-step over the instruction which generated the
> unwanted watchpoint exception, with the watchpoint disabled. Then after
> handling the single step reenable the watchpoint and resume normal
> execution.
>
> It would be best if you added watchpoint support to the kernel ptrace
> code: since that would make the watchpoints usable by GDB also.
>
> Nigel
>

Re: Using hardware watchpoint for applications debugging

[colin]

Hi Kevin,
After looking into function compute_return_epc(regs), we find that it can
just skip an instruction.
But the instruction that cause exceptions should not be skipped.

Regards,
Colin


----- Original Message ----- 
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Nigel Stephens" <nigel@mips.com>; "colin" <colin@realtek.com.tw>
Cc: <linux-mips@linux-mips.org>
Sent: Wednesday, March 29, 2006 10:32 PM
Subject: Re: Using hardware watchpoint for applications debugging


> > colin wrote:.
> > >     2. When an exception happens and we find that it's not touching
the righ
> > > address, we will discard it. However, exception will happen again
because
> > > the former instruction will be re-executed when the exception is
finished.
> > >
> >
> > You'll need to single-step over the instruction which generated the
> > unwanted watchpoint exception, with the watchpoint disabled. Then after
> > handling the single step reenable the watchpoint and resume normal
> > execution.
>
> There's actually a simpler and more efficient approach in Linux.  The code
> already exists in the MIPS Linux kernel to "skip" the instruction
responsible
> for the current exception, because the situation also arises for emulated
> instructions.   In do_watch(), in the cases where you want to ignore the
> watchpoint, you should be able to just invoke compute_return_epc(regs)
> and return.  There should be no need to handle single-step exceptions
> or disable/reenable the watchpoint.
>
>             Regards,
>
>             Kevin K.

Re: Using hardware watchpoint for applications debugging

[colin]

Hi Kevin,
After looking into function compute_return_epc(regs), we find that it can
just skip an instruction.
But the instruction that cause exceptions should not be skipped.

Regards,
Colin


----- Original Message ----- 
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Nigel Stephens" <nigel@mips.com>; "colin" <colin@realtek.com.tw>
Cc: <linux-mips@linux-mips.org>
Sent: Wednesday, March 29, 2006 10:32 PM
Subject: Re: Using hardware watchpoint for applications debugging


> > colin wrote:.
> > >     2. When an exception happens and we find that it's not touching
the righ
> > > address, we will discard it. However, exception will happen again
because
> > > the former instruction will be re-executed when the exception is
finished.
> > >
> >
> > You'll need to single-step over the instruction which generated the
> > unwanted watchpoint exception, with the watchpoint disabled. Then after
> > handling the single step reenable the watchpoint and resume normal
> > execution.
>
> There's actually a simpler and more efficient approach in Linux.  The code
> already exists in the MIPS Linux kernel to "skip" the instruction
responsible
> for the current exception, because the situation also arises for emulated
> instructions.   In do_watch(), in the cases where you want to ignore the
> watchpoint, you should be able to just invoke compute_return_epc(regs)
> and return.  There should be no need to handle single-step exceptions
> or disable/reenable the watchpoint.
>
>             Regards,
>
>             Kevin K.

Re: Using hardware watchpoint for applications debugging

[Nigel Stephens]

colin wrote:
> As to adding watchpoint to kernel, there will be another problem.
> ASID in kernel is variable. Therefore, we cannot indicate which thread we
> want to watch by ASID.
> What we can do is setting G (global) bit to WatchHi Register and then all
> threads accessing that address will cause the exception.
> In the exception, it will filter the threads by PID to find out the thread
> we are watching.
>
>   

They're variable, but not very variable: the PID->ASID mapping will only
change when the ASIDs roll over and the ASID gets reallocated to a
different process, which will only happen after another 256 processes
have been created. But in that case your watched process will have to be
allocated a new ASID before it can run again. So you could, perhaps,
modify the TLB management code to clear the Watch registers whenever an
ASID belong to a process with watchpoints is recycled, and then
reprogram the Watch registers when such a process is allocated a new
ASID. Alternatively you could maintain pre-process copies of the Watch
registers, and context switch them along with other per-process register
state -- though that is adding context switch overhead to processes
which don't use watchpoints, and might not be popular with the maintainer.

Nigel

Re: Using hardware watchpoint for applications debugging

[Ralf Baechle]

On Thu, Mar 30, 2006 at 11:49:22AM +0100, Nigel Stephens wrote:

> They're variable, but not very variable: the PID->ASID mapping will only
> change when the ASIDs roll over and the ASID gets reallocated to a
> different process, which will only happen after another 256 processes
> have been created. But in that case your watched process will have to be
> allocated a new ASID before it can run again. So you could, perhaps,
> modify the TLB management code to clear the Watch registers whenever an
> ASID belong to a process with watchpoints is recycled, and then
> reprogram the Watch registers when such a process is allocated a new
> ASID. Alternatively you could maintain pre-process copies of the Watch
> registers, and context switch them along with other per-process register
> state -- though that is adding context switch overhead to processes
> which don't use watchpoints, and might not be popular with the maintainer.

That's not quite true; the kernel also uses the ASID as a way to flush
a context from the TLB very quickly.

  Ralf

Re: Using hardware watchpoint for applications debugging

[Daniel Jacobowitz]

On Thu, Mar 30, 2006 at 11:49:22AM +0100, Nigel Stephens wrote:
> They're variable, but not very variable: the PID->ASID mapping will only
> change when the ASIDs roll over and the ASID gets reallocated to a
> different process, which will only happen after another 256 processes
> have been created. But in that case your watched process will have to be
> allocated a new ASID before it can run again. So you could, perhaps,
> modify the TLB management code to clear the Watch registers whenever an
> ASID belong to a process with watchpoints is recycled, and then
> reprogram the Watch registers when such a process is allocated a new
> ASID. Alternatively you could maintain pre-process copies of the Watch
> registers, and context switch them along with other per-process register
> state -- though that is adding context switch overhead to processes
> which don't use watchpoints, and might not be popular with the maintainer.

If you want GDB to use them, you almost certainly want them to be
per-process.  You can context switch them lazily, though.  We've solved
this problem before plenty of times...

-- 
Daniel Jacobowitz
CodeSourcery