From owner-freebsd-arch Wed Jan 30 12:40:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id B515D37B41B for ; Wed, 30 Jan 2002 12:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020130204010.BSOQ10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 30 Jan 2002 20:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA57603; Wed, 30 Jan 2002 12:30:04 -0800 (PST) Date: Wed, 30 Jan 2002 12:30:04 -0800 (PST) From: Julian Elischer To: Dag-Erling Smorgrav Cc: Doug White , Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 30 Jan 2002, Dag-Erling Smorgrav wrote: > Julian Elischer writes: > > The current debug code seems to call psignal to deliver STOP signals in > > order to suspend the process, and the stuff SEF did actually makes teh > > processes call msleep(). > > There are three different debugging interfaces in the kernel: > ktrace(2), ptrace(2) and procfs(5). Only procfs(5) (which is used by > truss(1) et al.) uses msleep(9); ptrace(2) (which is POSIX, and is > what gdb(1) uses) uses psignal(9). The procfs(5) junk is going away > as soon as I've finished my ptrace(2)-based version of truss(1), so > don't worry about it. > > > For example: do you want all teh other threads to be suspended, or to be > > running? Do you want the UTS to be suspended as well? > > As far as ptrace(2) is concerned, I think I want all threads to be > suspended; ptrace(2) doesn't really support the concept of threads. > Our current version of gdb(1) doesn't support threads either (AFAIK), > and I don't know if (or how) newer versions of gdb(1) do; we'll cross > that bridge when we get there. > > > I have not completed this work yet.. > > but am wondering if you have any violent arguments about what I'm doing.. > > Not really. It just has to work *somehow*, and I don't really have > any opinion on precisely how. The one request i have is that > debugging single-threaded processes should work the way it used to > (i.e. ptrace(2) should behave the same with single-threaded processes > under KSE as it did pre-KSE) That is my goal, but it may be achieved by using the new call rather than using psignal() to do the work. On your proposed changes, will truss continue to be able to debug linux binaries? will linux-gdb be able to work on FreeBSD? (for Linux binaries?) > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message