2010-04-02 00:22:33 +02:00
|
|
|
#include "kernel/kernel.h"
|
2010-09-15 16:09:36 +02:00
|
|
|
#include "arch_proto.h"
|
this patch adds access to the debug breakpoints to
the kernel. They are not used atm, but having them in trunk allows them
to be easily used when needed. To set a breakpoint that triggers when
the variable foo is written to (the most common use case), one calls:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_GLOBAL |
BREAKPOINT_FLAG_RW_WRITE |
BREAKPOINT_FLAG_LEN_4);
It can later be disabled using:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_OFF);
There are some limitations:
- There are at most four breakpoints (hardware limit); the index of the
breakpoint (0-3) is specified as the second parameter of
breakpoint_set.
- The breakpoint exception in the kernel is not handled and causes a
panic; it would be reasonably easy to change this by inspecing DR6,
printing a message, disabling the breakpoint and continuing. However,
in my experience even just a panic can be very useful.
- Breakpoints can be set only in the part of the address space that is
in every page table. It is useful for the kernel, but to use this for
user processes would require saving and restoring the debug registers
as part of the context switch. Although the CPU provides support for
local breakpoints (I implemened this as BREAKPOINT_FLAG_LOCAL) they
only work if task switching is used.
2010-03-19 20:15:20 +01:00
|
|
|
|
|
|
|
#include "debugreg.h"
|
|
|
|
|
2011-06-09 16:09:13 +02:00
|
|
|
PUBLIC int breakpoint_set(phys_bytes linaddr, int bp, const int flags)
|
this patch adds access to the debug breakpoints to
the kernel. They are not used atm, but having them in trunk allows them
to be easily used when needed. To set a breakpoint that triggers when
the variable foo is written to (the most common use case), one calls:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_GLOBAL |
BREAKPOINT_FLAG_RW_WRITE |
BREAKPOINT_FLAG_LEN_4);
It can later be disabled using:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_OFF);
There are some limitations:
- There are at most four breakpoints (hardware limit); the index of the
breakpoint (0-3) is specified as the second parameter of
breakpoint_set.
- The breakpoint exception in the kernel is not handled and causes a
panic; it would be reasonably easy to change this by inspecing DR6,
printing a message, disabling the breakpoint and continuing. However,
in my experience even just a panic can be very useful.
- Breakpoints can be set only in the part of the address space that is
in every page table. It is useful for the kernel, but to use this for
user processes would require saving and restoring the debug registers
as part of the context switch. Although the CPU provides support for
local breakpoints (I implemened this as BREAKPOINT_FLAG_LOCAL) they
only work if task switching is used.
2010-03-19 20:15:20 +01:00
|
|
|
{
|
2010-04-28 10:35:05 +02:00
|
|
|
unsigned long dr7, dr7flags;
|
this patch adds access to the debug breakpoints to
the kernel. They are not used atm, but having them in trunk allows them
to be easily used when needed. To set a breakpoint that triggers when
the variable foo is written to (the most common use case), one calls:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_GLOBAL |
BREAKPOINT_FLAG_RW_WRITE |
BREAKPOINT_FLAG_LEN_4);
It can later be disabled using:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_OFF);
There are some limitations:
- There are at most four breakpoints (hardware limit); the index of the
breakpoint (0-3) is specified as the second parameter of
breakpoint_set.
- The breakpoint exception in the kernel is not handled and causes a
panic; it would be reasonably easy to change this by inspecing DR6,
printing a message, disabling the breakpoint and continuing. However,
in my experience even just a panic can be very useful.
- Breakpoints can be set only in the part of the address space that is
in every page table. It is useful for the kernel, but to use this for
user processes would require saving and restoring the debug registers
as part of the context switch. Although the CPU provides support for
local breakpoints (I implemened this as BREAKPOINT_FLAG_LOCAL) they
only work if task switching is used.
2010-03-19 20:15:20 +01:00
|
|
|
|
|
|
|
if (bp >= BREAKPOINT_COUNT)
|
|
|
|
return EINVAL;
|
|
|
|
|
|
|
|
/* convert flags */
|
|
|
|
dr7flags = 0;
|
|
|
|
switch (flags & BREAKPOINT_FLAG_RW_MASK) {
|
|
|
|
case BREAKPOINT_FLAG_RW_EXEC: dr7flags |= DR7_RW_EXEC(bp); break;
|
|
|
|
case BREAKPOINT_FLAG_RW_WRITE: dr7flags |= DR7_RW_WRITE(bp); break;
|
|
|
|
case BREAKPOINT_FLAG_RW_RW: dr7flags |= DR7_RW_RW(bp); break;
|
|
|
|
default: return EINVAL;
|
|
|
|
}
|
|
|
|
switch (flags & BREAKPOINT_FLAG_LEN_MASK) {
|
|
|
|
case BREAKPOINT_FLAG_LEN_1: dr7flags |= DR7_LN_1(bp); break;
|
|
|
|
case BREAKPOINT_FLAG_LEN_2: dr7flags |= DR7_LN_2(bp); break;
|
|
|
|
case BREAKPOINT_FLAG_LEN_4: dr7flags |= DR7_LN_4(bp); break;
|
|
|
|
default: return EINVAL;
|
|
|
|
}
|
|
|
|
switch (flags & BREAKPOINT_FLAG_MODE_MASK) {
|
|
|
|
case BREAKPOINT_FLAG_MODE_OFF: break;
|
|
|
|
case BREAKPOINT_FLAG_MODE_LOCAL: dr7flags |= DR7_L(bp); break;
|
|
|
|
case BREAKPOINT_FLAG_MODE_GLOBAL: dr7flags |= DR7_G(bp); break;
|
|
|
|
default: return EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* disable breakpoint before setting address */
|
|
|
|
dr7 = st_dr7();
|
|
|
|
dr7 &= ~(DR7_L(bp) | DR7_G(bp) | DR7_RW_MASK(bp) | DR7_LN_MASK(bp));
|
|
|
|
ld_dr7(dr7);
|
|
|
|
|
|
|
|
/* need to set new breakpoint? */
|
|
|
|
if ((flags & BREAKPOINT_FLAG_MODE_MASK) == BREAKPOINT_FLAG_MODE_OFF)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* set breakpoint address */
|
|
|
|
switch (bp) {
|
|
|
|
case 0: ld_dr0(linaddr); break;
|
|
|
|
case 1: ld_dr1(linaddr); break;
|
|
|
|
case 2: ld_dr2(linaddr); break;
|
|
|
|
case 3: ld_dr3(linaddr); break;
|
2010-04-01 16:30:36 +02:00
|
|
|
default: panic("%s:%d: invalid breakpoint index", __FILE__, __LINE__);
|
this patch adds access to the debug breakpoints to
the kernel. They are not used atm, but having them in trunk allows them
to be easily used when needed. To set a breakpoint that triggers when
the variable foo is written to (the most common use case), one calls:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_GLOBAL |
BREAKPOINT_FLAG_RW_WRITE |
BREAKPOINT_FLAG_LEN_4);
It can later be disabled using:
breakpoint_set(vir2phys((vir_bytes) &foo), 0,
BREAKPOINT_FLAG_MODE_OFF);
There are some limitations:
- There are at most four breakpoints (hardware limit); the index of the
breakpoint (0-3) is specified as the second parameter of
breakpoint_set.
- The breakpoint exception in the kernel is not handled and causes a
panic; it would be reasonably easy to change this by inspecing DR6,
printing a message, disabling the breakpoint and continuing. However,
in my experience even just a panic can be very useful.
- Breakpoints can be set only in the part of the address space that is
in every page table. It is useful for the kernel, but to use this for
user processes would require saving and restoring the debug registers
as part of the context switch. Although the CPU provides support for
local breakpoints (I implemened this as BREAKPOINT_FLAG_LOCAL) they
only work if task switching is used.
2010-03-19 20:15:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* set new flags */
|
|
|
|
dr7 |= dr7flags;
|
|
|
|
ld_dr7(dr7);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|