Hi,
Yes, the case you mentioned is possible in current KDB. I remember some
related instructions in the KDB man pages. It is said that don't remove any break
point when you enter KDB through DEBUG trap or Int3 trap, disable it instead and
remove it safely later when you enter KDB via keyboard trap or serial port trap.
Maybe your patch can clean up these comments in the man pages?
Regards.
Sonic Zhang
-----Original Message-----
From: Vamsi Krishna S . [mailto:[EMAIL PROTECTED]
Sent: 2003?4?3? 14:59
To: Zhang, Sonic
Cc: Keith Owens; Hua Qin; [EMAIL PROTECTED]
Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously)
Hi,
Thanks for the clarification. I thought from my quick
glance through that currently all hard breakpoints
are global, whereas your patches enabled per-cpu
breakpoints. On second look, you are right, the current
code allows only per-cpu debugreg-breakpoints, global
ones are much more generally useful, which your patch
enables.
I also agree with the name changes and the fact that
per-cpu breakpoints may be useful for debugging certain
paths (processes) bound to a specific cpu.
smphdr* patches are very much needed.
Thanks,
Vamsi.
BTW: Can you think about what happens if two debugreg
breakpoints are triggered at about the same time on
different cpus? One of them wins the race to enter
the kdb, and then the user clears all breakpoints..
will kdb be able still recognise this as one of its
breakpoints? I think not, but can you give it a thought?
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: [EMAIL PROTECTED]
