From owner-freebsd-hackers Thu Jul 8 19: 0: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id CAEA114C93 for ; Thu, 8 Jul 1999 18:59:57 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id VAA10163; Thu, 8 Jul 1999 21:59:35 -0400 (EDT) Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA08796; Thu, 8 Jul 1999 21:59:04 -0400 Received: (from brdean@localhost) by dean.pc.sas.com (8.9.3/8.9.3) id VAA24535; Thu, 8 Jul 1999 21:59:01 -0400 (EDT) (envelope-from brdean) From: Brian Dean Message-Id: <199907090159.VAA24535@dean.pc.sas.com> Subject: Re: support for i386 hardware debug watch points In-Reply-To: <199907082357.TAA74127@lakes.dignus.com> from Thomas David Rivers at "Jul 8, 1999 07:57:09 pm" To: rivers@dignus.com (Thomas David Rivers) Date: Thu, 8 Jul 1999 21:59:01 -0400 (EDT) Cc: peter@netplex.com.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Thomas David Rivers > > 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