Linus Torvalds wrote:
quoted text
> [ The exception being that I think hw breakpoint support should be added
> back in - never mind that it won't work if the "native kernel" also uses
> them. Tough.
>
> If the debugger screws up the hw breakpoint state, that's a debugger
> error. I'd hope that the remote debugger *defaults* to just re-writing
> the instruction stream for that reason, but if you want to do a data
> breakpoint, you simply *have* to use the hw breakpoints for kgdb.
>
> And you just need to live with the fact that it simply won't be possible
> to do if the client wants to use hw breakpoints too. If the client
> starts using hw breakpoints - tough titties, it takes them. ]
>
> So keep the damn thing really simple, and don't try to handle every
> possible thing. We expect the debugger side to have a person with some
> flexibility on it.
>
> Linus

HW breakpoints (particularly data breakpoints) are extremely useful
and I am proposing to put them back into kgdb-light. The HW
breakpoint patch worked exactly as described. If the user space
writes into the HW breakpoint registers via ptrace, those take
priority over the kernel HW breakpoints.

We have to assume that the person debugging the kernel ultimately has
full control of the system, and will do what ever is needed to
debug/inspect the kernel how he or she chooses.

Of course at some future time if there is a generic API to use for the
kernel level HW breakpoints, kgdb can adapt like anything else.

Jason.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/