|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 28 Aug 1996 03:06:29 -0700 From: Pete Delaney <peted@swdc.stratus.com> To: mueller@hp832.informatik.hu-berlin.de In-Reply-To: <199608280732.JAA27781@mail.informatik.hu-berlin.de> Cc: bug-gdb@prep.ai.mit.edu, gdb-local@cygnus.com, pthreads@MIT.EDU --------- Received message begins Here --------- > > From peted@swdc.stratus.com Wed Aug 28 02:27:55 1996 > > Since threads can cross into LWP and other Processes I thought it would > > be rather helpfull if we can follow processes when they fork with a > > clone of GDB. GDB currently leaves the breakpoints in place during a fork > > and the child process gets a SIGTRAP. I was wondering if in the process > > of developing the Tk/Tcl GUI interface to GDB you had considered the > > difficulty in enhancing GDB to follow a forking process as I recall SunSoft's > > Debugger (enhanced dbxtool) can do as well as a Silicon Graphics Debugger > > on their systems about 10 years ago. I thought it might not be that difficult > > and someone likely has investigated the difficulty or have taken a shot at > > trying it. I just downloaded the latest gdbtk-4.16.tar from Cygnus but > > haven't had a chance to try it. > > We've experimented with thread-specific breakpoints, info threads and > some other enhancements/modifications to gdb to make it FSU Pthreads > aware. But we haven't made it to a release level. gdb already offers > thread services. One needs to plug in the proper interface to the > thread package and voila -- to some extend. It may be helpfull to send me what you have experimented with and let me check it out as is. I just compiled your (FSU?) Pthreads and I'm trying to build the MIT one right now. Yours was a snap, thanks. I'm also building the latest gdbtk. I've seen the threads stubs in the kernel debugging interface but didn't know how to use it in the SunOS kernel. Like you I thought that it might bolt in to the threads package without too much effort. > We have not experimented with breakpoints durign fork etc. I don't > think this is necessary since threads have a different nature than > processes: They share memory and (for a uniprocessor) run > concurrently. Thus, it is sufficient to implement "next" and "step" > commands with two flavors: One flavor transfers control to a new > thread if a context switch occurs, the other flavor only keeps on > going in the current thread. More complicated command can be build on > top. Im doing this in a Stratus System V.4 without Light Weight Processes implemented. I suspect implementing LWP's for user space processing wouldn't be that difficult. So curently the only way of testing/supporting the PTHREAD_SCOPE_GLOBEL stuff would be with real procs. Either way your idea of extending "next" and "step" sounds interesting. I kinda thought the reason that a guys using threads is to think about these different parts of the code as independant processes. Just as in the kernel it would be nice to breakpoint indivdual processes. On the HP Symbolic Debugger, RsDdb, I wrote macro's to removed breakpoints when I called swtch() for the current process and placed them back in the kernel text when I came back out with resume(). It was great for debugging the NFS code while is was in some of the VFS directory caching code. I would think it would be ideal to have a GUI interface for every thread, if desired, so you could place breakpoints, single step, and next step in each thread independantly. Unfortunately the GDB internals paper that your web page didn't seem to cover that kind of stuff (at least what I read last night before going to bed). > Right now, you'll get the first flavor. This can be annoying when you > really don't want to switch contexts but you don't have the > choice. I'd love to see someone follow up on this. Right and our customers likely expect a bit more. Seems to me the debugger will know the context from the threads interface in the low end of GDB. Perhaps like my RsDdb swtch() resume() hack the Pthreads process switching should be involved with the debugger. I just had a thought, a new signal, SIGSWTCH perhaps, that ptrace could use to inform the debugger of the change. Many archectures have a cache for each context. Perhaps with our quick system calls we could switch the context when we change threads, resulting in a bit better performance because the caches wouldn't be flushed as often, and if the process is being ptraced we could post a signal for the debugger to remove the breakpoints of the current context and install the breakpoints of the new context. Most machines have lots of left over user space traps, we could add a new kind of trace point that indicates a context change. I wonder whats best. > > Perhaps you and the others have some suggestions on using GDB with > > Pthreads, including the global scope of multiple processes, > > > > PTHREAD_SCOPE_GLOBEL > > FSU Pthreads does not support threads across processes, only within > one process. This is not likely to change due to the nature of a > strict library implementation. (You'd need OS kernel support.) Perhaps you could recommend the OS kernel support that YOU would like to see implemented. I'm in the OS kernel group and it's part of our job to implement this best, thus including reasonable kernel extensions. I've wondered about things like adding user space light weight processes (SunOS has this doesn't it?), and just a moment ago a context switch signal or trap. I'd wager you had a lot of ideas of nice hooks to have in the kernel while you were doing all of this work. How about taking some time one of these days to recall some of them an let me/us know some of when it's convenient. While reading your papers I got the impression that Signal processing was difficult because the threads libraries lacked the equivalent of a splhi() to disable signals/interups quicky. We have special system calls that are extremely fast and don't even flush the cache. One of the guys just added a system call to access the High Speed Nano-Second clock via one of these high speed system calls. So I think I could likely set a bit somewhere to delay signals to the thread library while it's doing stuff like switching stacks. We could have a threads_swtch() and a threads_resume() high speed system calls to disable the process delivery of signals while switching, change the hardware context to the new frame, and if ptrace() is active to post a SIGSWTCH (SIGCONTEXT?) or take a THREAD_SWTCH_TRAP. > Let me know if you have questions or suggestions. I hope I'm not takeing too much of your time. No hurry, I have lots of stuff to read, I gave copies of your papers to the gang here and I think they all appreciated it. Since we don't have to limit this implementation to the existing system call interface it's an interesting problem what minimal set of kernel extensions would be most helpfull in implementing Pthreads. > -- > Frank Mueller > Humboldt-Universitaet zu Berlin > E-Mail : mueller@informatik.hu-berlin.de > WWW URL: http://www.informatik.hu-berlin.de/~mueller -pete --------------------------------------------------------------------- Pete Delaney - Rm:153 pete@Rahul.Net Stratus Western Development Center pete@rm.Rahul.Net peted@SWDC.Stratus.Com pete@RockyMountain.Rahul.Net (408) 559-5332 (408) 243-8872 ----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |