Hi,

        In the formal KDB patch, the user can create both local and global hardware 
breakpoints. But the code within kdb_bp_install_global() doesn't install the global 
hardware breakpoint into each CPU. Because kdb_bp_install_global() is only executed by 
the initial CPU, while other CPUs only install its local breakpoints in 
kdb_bp_install_local(). That means the only way to create a global hardware break 
point is to create one local hardware breakpoint in one CPU, then switch to another 
CPU and create a new local hardware breakpoint at the same address. In KDB v4.0 patch, 
there is no way to create 2 breakpoints for one address. So smphdr patch is helpful 
especially for KDB v4.0.

        What I did in smphdr patch is to move the installation of both local and 
global hardware breakpoints into function kdb_bp_install_local(), while keep the 
instruction ones in the function kdb_bp_install_global(). I also renamed the two 
functions according to their logic. In this way, command "bpha" takes effect.

        In addition, some kernel patches support cpu affinity. A process can be 
confined to a specific subset of CPUs, even a specific CPU. With the support of 
different hardware breakpoints on different CPUs, you can create at most 4*2 hardware 
breakpoints when debug bugs caused by running 2 processes concurrently, 4 for each 
process. This feature is not commonly used, but it also do no harm.

        Do you have more advices?

        Thanks.

        Sonic Zhang


-----Original Message-----
From: Vamsi Krishna S . [mailto:[EMAIL PROTECTED]
Sent: 2003?4?1? 16:27
To: Zhang, Sonic
Cc: Keith Owens; Hua Qin; [EMAIL PROTECTED]
Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously)


smphdr patch  does two things AFAICS:
- s/kdb_bp_*_local/kdb_bp_*_dbreg and
  s/kdb_bp_*_global/kdb_bp_*_dbinst

- keep the state of debug registers per-cpu, so that you could implement
  per-cpu breakpoints, as probably intended in bph and bpha commands.

I think these patches are okay, but unrelated to my patch. Regarding
the smphdr patches, in my opinion, they are not really needed.. I don't
see how cpu-local breakpoints are useful.. how can one tell on which
particular CPU alone a given piece of code executes. Sonic Zhang,
can you please explain why this is needed and correct me if I am
wrong about the smphdr patch.

BTW: my patch is useful to detect and handle conditions in which 
multiple cpus hit breakpoints at about the same time, one of them
wins the race to enter into kdb, and at the kdb prompt, the user 
removes all breakpoints.. so we won't be able to find KDB breakpoints
on other cpus when they eventually enter KDB thereby causing 
unhandled trap3/trap1 in kernel -> oops. My patch is needed for
both instruction-replacement breakpoints and debug-reg assisted
breakpoints. I will post an updated patch.

Thanks,
Vamsi.

On Tue, Apr 01, 2003 at 09:47:02AM +0800, Zhang, Sonic wrote:
> Hi,
> 
>       The "smphdr" patch only deal with the hardware breakpoints. It doesn't affect 
> the logic of "int3" instruction breakpoint in the formal KDB patch. So if this 
> problem occurs in the formal KDB patch, it is very possible that it still exists 
> after applying the "smphdr" patch.
> 
>       Thanks.
> 
>       Sonic Zhang
> 
> 
> -----Original Message-----
> From: Keith Owens [mailto:[EMAIL PROTECTED]
> Sent: 2003?3?31? 19:02
> To: [EMAIL PROTECTED]
> Cc: Hua Qin; [EMAIL PROTECTED]
> Subject: Re: [PATCH] kdb on SMP (breakpoint hits multiple cpus simultaneously) 
> 
> 
> On Mon, 31 Mar 2003 15:40:16 +0530, 
> "Vamsi Krishna S ." <[EMAIL PROTECTED]> wrote:
> >Here is a simple way to handle this situation. Before deciding that 
> >this trap is not due to one of KDB's breakpoints, check if this
> >is a breakpoint that was recently removed.
> 
> Sonic Zhang has cleaned up the breakpoint handling.  I am waiting for
> feedback on these patches before including them in kdb.
> ftp://oss.sgi.com/projects/kdb/download/v4.0/kdb-smphdr-v4.0-2.4.20*
> 

-- 
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: [EMAIL PROTECTED]


Reply via email to