Date: Wed, 30 Jan 2002 11:12:57 -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.0201301041130.57066-100000@InterJet.elischer.org> In-Reply-To: <xzpk7tz7kfu.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In a threaded world, the assumption that gdb makes in teh current kernel that 1 process == 1 thread totally breaks down. Another thing that breaks down is the way in which processes are suspended. This also impacts on how processes are debugged as suspending the process is part of debugging it. I have made the following changes: Addition of three 'suspended' flags in the process structure flag word. One for a new concept "singlethreading", one to indicate that the process received a SIGSTOP or SIGTSTP and one to indicate that the process was asked to stop for tracing reasons. If any of these three are set, then any associated threads will refuse to go to user mode but will instead block at userret() and be placed upon a special 'suspended' queue off the process itself. "Singlethreading" is a suspension mode where a thread requests that all threads OTHER THAN ITSELF be placed into suspended mode (or in fact forced to call thread_exit()). This is required during such things as fork(), exit() , exec(). The requesting thread is itself suspended and placed on a special hook until all the other threads have suspended or died, at which time it is made runnable again. 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(). I hope to replace all these calls in both systems with calls to new functions trace_suspend(p) and trace_unsuspend(p). So that both sets of debug code use the same mechanism. The difficult part is to decide how the interface should be modified to debug single threads. 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? User threads are identified by the address of their mailbox. The UTS has it's own mailbox (per cpu) and when it schedules a thread to run, it places a pointer to that thread's mailbox in a know location in ITS mailbox. If there is a trap or syscall, and the kernel is entered, that entry is examined and thus the kernel knows the mailbox address of the currently running thread. It would be possible to only suspend a thread that has a particular address, or to only allow a thread with that mailbox address to continue, etc. When teh UTS is running itself that entry contains NULL. This on any kernel entry, the kernel can tell if the user thread running is the one it is interested in or not, or if the UTS itself is running. I have not completed this work yet.. but am wondering if you have any violent arguments about what I'm doing.. On 30 Jan 2002, Dag-Erling Smorgrav wrote: > Julian Elischer <julian@elischer.org> writes: > > I'm not actually looking for a gdb maintainer, so much as someone who > > understands teh KERNEL side of how gdb controls a process. > > That'd be me. Feel free to ask any questions you might have. > > 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 > 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.0201301041130.57066-100000>