Re: [RFC][PATCH] Debug Register Allocation on x86

Hello Jim,

We have modified ptrace() such that it first allocates the debug register
before it is used. So, yes, if a debugger is using ptrace() interface it
need not be concerned about this centralised debug register allocation
scheme, the debug register allocation actually happens behind the scenes
and it is guaranteed that other debug facilities don't overwrite your
settings. However, when you try to access a debug register for the first
time using ptrace, be sure to check the return value. It can return -EBUSY
if the debug register you are trying to use is already being used by other
tool.

You cannot rely on determining free debug registers by checking dr7: it is
possible that a debug register can be allocated from under you after you
have checked that it is free but before you have updated dr7 with new
settings.

Regards.. Vamsi.

Vamsi Krishna S.
Linux Technology Center, IBM India, Bangalore.
Ph: [phone] Extn: 3672
Internet: [e-mail]

---------------------- Forwarded by Bharata B Rao/India/IBM on 04/04/2001
08:49 AM ---------------------------

James Cownie <[e-mail]> on 04/03/2001 09:53:22 PM

Please respond to James Cownie <[e-mail]>

To:   Bharata B Rao/India/IBM@IBMIN
cc:   John DelSignore <[e-mail]>
Subject:  [RFC][PATCH] Debug Register Allocation on x86

Bharata,

If I understand your patch correctly, it does not require that code
using the debug registers via ptrace is changed, since you notice the
use of a debug register in the ptrace write request and then allocate
it ?

Is this right ?

Our TotalView debugger also uses the debug registers to implement data
watchpoints on Linux/x86, and we search for free watchpoint registers
by looking at the control register, and then update all of the
watchpoint registers (skipping dr4 and dr5). I'm not sure how this
will work with your code...

p.s. You can download a copy of Totalview and get a demo license from
the web if you want to play with it.

Reference :
http://boudicca.tux.org/hypermail/linux-kernel/this-week/0322.html

-- Jim

James Cownie   <[e-mail]>
Etnus, LLC.     [phone]
http://www.etnus.com