Date: Thu, 8 Jul 1999 21:59:01 -0400 (EDT) From: Brian Dean <brdean@unx.sas.com> To: rivers@dignus.com (Thomas David Rivers) Cc: peter@netplex.com.au, freebsd-hackers@FreeBSD.ORG Subject: Re: support for i386 hardware debug watch points Message-ID: <199907090159.VAA24535@dean.pc.sas.com> In-Reply-To: <199907082357.TAA74127@lakes.dignus.com> from Thomas David Rivers at "Jul 8, 1999 07:57:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Thomas David Rivers <rivers@dignus.com>
>
> I just wondered if this should be integrated into ptrace(), so
> the various debuggers wouldn't have to know about it.
>
> It seems that would be the proper abstraction - hardware that supports
> it would "have it" - and the programs that "used it" wouldn't have to
> know anything special.
>
>
> I only have a passing knowledge of ptrace() - so, I may be totally wrong...
>
> - Dave Rivers -
I think 'ptrace()' provides a natural interface for doing this. Under
the covers, the 'ptrace()' calls are actually mapped to the
corresponding procfs filesystem calls. While it is certainly possible
to get at the registers using the more direct /proc/$pid/dbregs file,
for historical reasons, the 'ptrace()' interface is probably the more
expected method, and does not require issuing an open(), read(),
write(), close() sequence.
I've studied the code for 'gdb', and specifically the Linux support
for their hardware debug registers. They use:
ptrace (6, pid, offsetof (struct user, u_debugreg[DR_CONTROL]),
debug_control_mirror);
ptrace (6, pid, offsetof (struct user, u_debugreg[free_debug_register]),
addr);
Why they've hardcoded a '6' there I can't fathom, but it represents
the PT_WRITE_U request to write directly into the child's user
structure. Not only does this method require knowledge of x86 debug
registers, but it also requires some knowledge of Linux internals. By
providing a PT_[GET/SET]DBREGS request to 'ptrace()' in FreeBSD, which
not by accident works identically to the existing PT_GET/SETREGS, and
PT_GET/SETFPREG for getting/setting the general purpose and floating
point processor registers, debuggers can focus on the hardware
architecture, without having to be too concerned with obscure offsets
of data within system data structures. In this respect, it actually
results in less information that the programmer has to be aware of or
keep track of.
As far as providing a higher layer of abstraction, I must argue that
these registers are primarily used only by debuggers, which must
possess a very detailed kowledge of the underlying hardware by
default. Thus, hiding the debug registers does not offer that much,
however, exposing them to the debugger for complete control, can
result in the complete debug support that is provided by the target
architecture, as opposed to the subset that is supported across
multiple architectures, that a higher level of abstraction implies.
I suppose that in my view, I don't really see any difference in
accessing the debug registers as accessing the general purpose
registers or floating point registers, which is the model I used for
this implementation. Also, this implementation currenly supports only
those features that are available all the way back to the i386.
Sorry for being so wordy. I should have provided some explanation for
some of the design decisions that I made for this implementation when I
posted my patches.
I certainly hope that this work will be committed, because I think it
adds a nice feature (once gdb supports it), especially for anyone who
does non-trivial software development and debugging.
Also, I must compliment the FreeBSD kernel folks ... the well designed
internals of FreeBSD allowed a very clean implementation of this
support. I did not have to do anything tricky to make it work. The
framework was essentially there, I just had to "plug in" at the
appropriate places in the kernel.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907090159.VAA24535>