Date: Wed, 14 Jan 2004 17:03:29 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: David Xu <davidxu@freebsd.org> Subject: Re: ptrace and thread Message-ID: <Pine.NEB.3.96L.1040114170123.49872J-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0401141324530.12875-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Jan 2004, Julian Elischer wrote: > On Wed, 14 Jan 2004, David Xu wrote: > > > I am current working on debug support for KSE thread program, however I > > found > > ptrace interface is not thread-aware, in a threaded program, I need to > > get/set registers > > set for individual threads, current ptrace can not support that > > features, there are two > > ways to support these requirements: > > Yes I tried to address this a bit around the time when I added the > single ttreading code. Ialso made several posts looking for advice from > gdb/ptrace experts but got very little response.. As you noticed, the > ptrace facility is almost completely useless WRT threads.. > > it is possible to imagine an extension where you select a single thread > of interest but you would have to decide whether you want all the other > threads to be left running or left suspended.. (you may need both > possibilities to correctly debug a problem) > > The problem is that the thread becomes invisible to the kernel when it > crosses over to userland so the UTS needs to take an active part, > (unless the kernel can recognise when the thread has yielded and the UTS > has been enterred. (possible I guess) at which time single stepping > would be turned off allowing the UTS to run at full speed. > > The UTS would hav eto co-operate by using a method of re-enterring the > thread that allows the kernel to re-start single stepping.. > > What the other threads are doing in teh meanwhile is unknown. Apparnelty one common model is to get the application's (or threading package's) help in the debugging process. Teach gdb to talk to libkse, and have libkse provide the information on threading to gdb, as well as do the scheduling/assert control. FWIW, I think ptrace/procfs are in a somewhat broken state following KSE -- stuff like gdb works, but strace is known to hang. Part of the problem appears to be slightly different models for stopping the process -- p_step vs p_stop(). I'm still getting my head around the details of the debugging facilities, which is complicated by the fact that procfs is a lot more capable than the man page claims :-). I hope to dig more into the problem next week. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040114170123.49872J-100000>