Commit graph

3 commits

Author SHA1 Message Date
Arun Thomas
b0159ad168 Buildsystem changes for GCC
-Makefile updates
-Update mkdep
-Build fixes/warning cleanups for some programs
-Restore leading underscores on global syms in kernel asm files
-Increase ramdisk size
2010-05-19 13:24:15 +00:00
Erik van der Kouwe
84d404aba3 Fix types in debug register functions 2010-04-28 08:35:05 +00:00
Erik van der Kouwe
b42c66ed10 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 19:15:20 +00:00