From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26685 invoked by alias); 16 Jul 2010 21:40:00 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 26675 invoked by uid 22791); 16 Jul 2010 21:39:59 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov CC: archer@sourceware.org Subject: Re: Q: mutlithreaded tracees && clone/exit In-Reply-To: Oleg Nesterov's message of Friday, 16 July 2010 22:51:47 +0200 <20100716205147.GA26313@redhat.com> References: <20100716205147.GA26313@redhat.com> Message-Id: <20100716213950.7A7BC40B45@magilla.sf.frob.com> Date: Fri, 16 Jul 2010 21:40:00 -0000 X-SW-Source: 2010-q3/txt/msg00032.txt.bz2 [I trimmed the CC because everybody concerned should be on this list.] > In case this matters, I used gdb-7.1 for testing. I'm not the gdb expert. So I'll just say what I think is reasonable, and then we'll figure out where we need to change our thinking and where need to get gdb changed. > Q1: if gsbstub reported that the tracee has exited (say, we sent > '$X09#..' to gdb), can gsbstub assume it can forget about this thread? I think so. In the ptrace-based implementation of gdbserver, it sends X or W reports after it has done wait and gotten a death status. In Linux, that means the zombie is reaped and its PID is available for reuse. > The main question is, I do not understand how gdbstub should handle the > multithreaded targets. It's not really clear to me when gdb decides to ask for the thread list. It looks like it only does it at extended-remote attach time if you have set non-stop mode. > Q2: Shouldn't gdbstub let debugger know about sub-threads somehow? That's what I would expect in the abstract. But I know that gdb didn't used to get new-thread notifications from ptrace either. It looks like the linux-nat code does track PTRACE_EVENT_CLONE now. But it may be that the gdbserver code and remote protocol were made to match how things were when the native ptrace case didn't do that. gdb also uses higher-level knowledge read from user memory (libthread_db) for some aspects of thread tracking. I really don't know how the kernel-thread layer and the thread_db layer fit together in gdb at this point. But certainly historically it had means to get by without kernel facilities either for enumerating the live threads or for notifying of thread creation and death. libthread_db instructs gdb based on libpthread details read from the user memory, to extract the thread list and TIDs, and to set breakpoints in libpthread to tell it about thread creation and death. All that should be superfluous when proper low-level thread (LWP in gdbspeak) tracking is being done. But it's there historically, so in practice gdb could get by without whichever low-level layer (ptrace or remote or whatever) helping it. > I am asking because that I thought that gdb+gdbserver should > try to work the same way as it works without gdbserver, and > thus it should see clone/exit. I agree that's how it seems it should be. Thanks, Roland