Date: Wed, 14 Jan 2004 13:34:02 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: David Xu <davidxu@freebsd.org> Cc: arch@freebsd.org Subject: Re: ptrace and thread Message-ID: <Pine.BSF.4.21.0401141324530.12875-100000@InterJet.elischer.org> In-Reply-To: <4004B4D0.907@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 1. keep current ptrace interface, add a command for example > PT_SETDTHREAD to > set current thread for debug, and subsequent request for example > PT_SETREGS and > PT_GETREGS will work on the thread, for single thread process, the > default current > thread is always the first thread in the process, this way we needn't > change legacy debugger > code. yes.. > > 2. introduce a second ptrace syscall, and accept a new parameter tid > (thread id), > the PT_SETREGS and PT_GETREGS will use the tid to operate on > corresponding > thread. > as mentionned by others this is also what some other systems did. should this be in -arch or -threads? > For first method, I have a patch there: > http://people.freebsd.org/~davidxu/kse/ptrace.diff > The patch also includes some bits to support KSE debug, not just for > pure 1:1 threading. > > David Xu > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0401141324530.12875-100000>