Date: Wed, 30 Jan 2002 12:30:04 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Doug White <dwhite@resnet.uoregon.edu>, Sheldon Hearn <sheldonh@starjuice.net>, arch@FreeBSD.ORG Subject: Re: KSE milestone 3 reached. Message-ID: <Pine.BSF.4.21.0201301228020.57276-100000@InterJet.elischer.org> In-Reply-To: <xzp3d0n7h3a.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Jan 2002, Dag-Erling Smorgrav wrote: > Julian Elischer <julian@elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0201301228020.57276-100000>