Menu
▾
▴
Re: [Dprobes] RE: [Intel Internal Telecom Dev] Using dprobes in kernel space
|
From: Suparna B. <bsu...@in...> - 2002-04-30 15:52:06
|
The dr_alloc interface is purely meant for allocation of a debug register,
primarily to enable coordination of the use of debug registers by multiple
facilities. It doesn't actually set the values in the debug registers. The
latter is the caller's responsibility. Once a dr is allocated the caller
can be assured that no one else would be allocated that register, so it can
have sole control over it. The scheme works provided all users take care to
allocate a dr prior to using it.
Typically this is the sequence a caller might adopt:
alloc debug register (using dr_alloc)
set debug register and propagate to other cpus (via smp_call_function
or alternative means)
Notice that this is the way dprobes uses it (dprobes has code to set the dr
on all CPUs). Next time the same caller needs to alter the value of the dr,
it can do so directly knowing that it has it allocated already.
Different facilities may use different schemes for setting dr's on all CPUs
(e.g kdb takes a different approach, since it already has the other cpu's
held in kdb at the time, so it suffices to make sure the dr's are set when
it releases them from kdb)
And when all done, the caller invokes:
free debug register (using dr_alloc)
which makes it available to other callers for allocation.
(The allocation is of course system global)
Regards
Suparna
Suparna Bhattacharya
Linux Technology Center
IBM Software Lab, India
E-mail : bsu...@in...
Phone : 91-80-5044961
"Zhuang, Louis"
<lou...@in...> To: "Thomson, Patrick S"
Sent by: <pat...@in...>, "Howell,
dpr...@ww...uthbury.u David P" <dav...@in...>, "Wang,
sf.ibm.com Chenguang" <che...@in...>,
"'dev...@li...'"
<dev...@li...>
04/30/02 08:49 AM cc: S Vamsikrishna/India/IBM@IBMIN,
Please respond to "Zhuang, Louis" Dp...@ww...
Subject: [Dprobes] RE: [Intel Internal
Telecom Dev] Using dprobes in kernel space
Sorry for some misleading question :-). It is nothing with kdb.
Our truly concern is "when you set&alloc a debug register by dr_alloc(), it
seems that dr_alloc just sets current CPU's debugger register, not all
CPUs'. When you need to place a watchpoint in kernel space (not process
space, because switch_process() will set drs rightly before cpu is switched
into the process context), how could we do if we want that ALL CPUs can be
trapped when they run into a watchpoint?"
So we try to use smp_call_function() to let all CPUs set their drs at the
same time. Is it right? Beg for comments :-).
- Louis
-----Original Message-----
From: Thomson, Patrick S [mailto:pat...@in...]
Sent: 2002年4月30日 3:07
To: Howell, David P; Wang, Chenguang; 'dev...@li...'
Cc: 'S Vamsikrishna'; Dp...@ww...
Subject: RE: [Intel Internal Telecom Dev] Using dprobes in kernel space
Well, in the testing done thus far, we've had
dprobes and kdb running concurrently and kernel probes
have been inserted. I realize this is part of Dprobes
2.2, but debug register usage had remained the same
(as i understand things...). I still believe that
if we try to breakpoint in the same piece of code,
we'll have problems, but we've noted that already.
I'm not saying we shouldn't test it, but up to now,
there hasn't been a problem. We should enhance our
tests to intermix kdb and dprobes (i.e. break into the
kernel with kdb, and have a dprobes breakpoint in a
different section of code, but both are triggered in
the same test)
pat
-----Original Message-----
From: Howell, David P
Sent: Monday, April 29, 2002 9:31 AM
To: Thomson, Patrick S; Wang, Chenguang; 'dev...@li...'
Cc: 'S Vamsikrishna'
Subject: RE: [Intel Internal Telecom Dev] Using dprobes in kernel space
In my response I mucked the tools, I meant to say DProbes and kdb which
now both use the debug registers. Kdb assumes that it has full control,
as I read it, and I think that this is bad news WRT DProbes. Not sure
how we would to this other than noting that using the debug registers
with kdb and DProbes concurrently is bad.
For gdb I think that user mode use is ok as long as the debug registers
are part of the context for the user task, we need to check this.
Dave Howell
-----Original Message-----
From: Thomson, Patrick S
Sent: Monday, April 29, 2002 11:27 AM
To: Howell, David P; Wang, Chenguang; 'dev...@li...'
Cc: 'S Vamsikrishna'
Subject: RE: [Intel Internal Telecom Dev] Using dprobes in kernel space
Hi,
Actually, it has (as i understand it) been used by IBM
in a SMP environment and is cognizant of SMP (i.e.
being able to tell which cpu it is running). Also,
the you'll need to look at the patch for 3.3.0, as
that is the version being put into TLT. I do suspect
that the code between the two versions should be
similar.
As to Dave's concern regarding the debug registers, i don't
have an answer. It would really depend on whether or not
each feature uses the same registers, so state would
have to be maintained. I would expect that since dprobes is
aware of kdb, that they are using different debug
registers (or at least maintaining state). I'm copying
Vamsi from IBM so he can comment.
As far as validation, it is definately a good thing
to check. I would suspect that somewhere with all
the stuff being added, that there's going to be a
problem somewhere.
thanks
pat
-----Original Message-----
From: Howell, David P [mailto:dav...@in...]
Sent: Monday, April 29, 2002 7:25 AM
To: Wang, Chenguang; 'dev...@li...'
Subject: RE: [Intel Internal Telecom Dev] Using dprobes in kernel space
This ought to be another interesting area for kdb/LKCD interaction, i.e.
both
use the debug registers to implement their functionality. Since both may be
active in the kernel, who is protecting the state?
I'm assuming that we are safe for user programs (like gdb) setting up these
registers and expecting that they continue to do their thing across a
context
switch. We should validate that scenario as well. In the presence of thread
debugging of multi-process thread groups it's hard to see how this could
be.
Just a few thoughts of concern.
Thanks,
Dave Howell
-----Original Message-----
From: Wang, Chenguang [mailto:che...@in...]
Sent: Monday, April 29, 2002 5:39 AM
To: 'dev...@li...'
Subject: [Intel Internal Telecom Dev] Using dprobes in kernel space
Folks,
Has anybody used "dr_alloc" scheme offered by dprobes in kernel space?
After read source of dprobes' patch, I think it won't work in SMP
environment.
Is it correct?
I think the following code will not work properly in SMP environment.
+#define set_dr(regnum, val) \
+ __asm__("movl %0,0b" #regnum \
+ : /* no output */ \
+ :"r" (val))
+static inline void write_dr(int regnum, unsigned long val)
+{
+ switch(regnum) {
+ case 0: set_dr(0, val); break;
+ case 1: set_dr(1, val); break;
+ case 2: set_dr(2, val); break;
+ case 3: set_dr(3, val); break;
+ case 7: set_dr(7, val); break;
+ default: printk("write_dr: invalid debug register
0\n",
regnum);
+ break;
+ }
+ return;
( Copy form dprobes-v3.5.0-2.4.17.patch )
Maybe we should call "write_dr()" function in the following way:
struct foo {
int regnum;
unsigned long val;
};
void bar(void *info)
{
struct foo *p=(struct foo*)info;
write_dr( p->regnum, p->val);
}
and do this call when we want write sth into debug register
ret = smp_call_function(bar, info, nonatomic,wait);
Is it correct?
Thanks.
your sincerely,
Wang, chenguang (Stanley)
Intel China Software Lab
tel:02152574545*1171
INET:8-752-1171
_______________________________________________
Developer mailing list
Dev...@li...
http://linux.intel.com/mailman/listinfo/developer
_______________________________________________
Developer mailing list
Dev...@li...
http://linux.intel.com/mailman/listinfo/developer
_______________________________________________
Developer mailing list
Dev...@li...
http://linux.intel.com/mailman/listinfo/developer
_______________________________________________
Dprobes mailing list
Dp...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dprobes
|