From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31170 invoked by alias); 19 Jul 2010 22:57:12 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 31156 invoked by uid 22791); 19 Jul 2010 22:57:11 -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: Jan Kratochvil Cc: Oleg Nesterov , archer@sourceware.org Subject: Re: Q: mutlithreaded tracees && clone/exit In-Reply-To: Jan Kratochvil's message of Monday, 19 July 2010 18:01:27 +0200 <20100719160127.GA13331@host1.dyn.jankratochvil.net> References: <20100718174851.GA15528@redhat.com> <20100716205147.GA26313@redhat.com> <20100719160127.GA13331@host1.dyn.jankratochvil.net> Message-Id: <20100719225704.E957A40840@magilla.sf.frob.com> Date: Mon, 19 Jul 2010 22:57:00 -0000 X-SW-Source: 2010-q3/txt/msg00039.txt.bz2 > This issue does not work well even with linux-nat.c (local GDB), in the > current development stage of ugdb I believe we do not have to solve it before > linux-nat.c gets fixed first: > GDB hangs with simple multi-threaded program on linux > http://sourceware.org/ml/gdb/2010-07/msg00045.html On the contrary, this is something where not being ptrace makes an important difference. The ptrace behavior that makes this difficult to deal with in linux-nat.c is not at all an inherent issue with the scenario, it's just a quirk of the ptrace interface. The fact that linux-nat.c doesn't handle it well means that it's not a big priority to handle it better than that. But it's certainly not the case that linux-nat.c improving its support would have anything to do with how ugdb would do it. > GDB will sooner or later use the 'T' packet (remote_thread_alive) to reclaim > dead threads. For this to be correct, it must be using multiprocess mode so that its packet says Tn.m instead of just Tm. In the latter case, the TID m may have been reused for an unrelated new thread. > IMO yes, we should first get ugdb a bit on-par with linux-nat.c, don't we? Sure. But we should carefully note all the ways in which that standard of comparison is less than ideal. > > gdbserver asks gdb what is the symbol's address (say, _thread_db_list_t_next) > > via 'qSymbol'. > > i see this can be a problem for ugdb. Guessing we will need to change GDB to > support new variant of proc-service.c working over the GDB protocol wire. proc-service.c is already written in terms of the gdb target backend. I had presumed that all this thread_db layer of concern would happen above the LWP layer, and the remote protocol supplies the LWP layer. Thanks, Roland