From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4628 invoked by alias); 24 Aug 2010 23:36:16 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 4616 invoked by uid 22791); 24 Aug 2010 23:36:15 -0000 X-SWARE-Spam-Status: No, hits=-4.4 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 X-Fcc: ~/Mail/utrace Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v5 In-Reply-To: Oleg Nesterov's message of Friday, 20 August 2010 19:37:49 +0200 <20100820173749.GA24358@redhat.com> References: <20100820173749.GA24358@redhat.com> Message-Id: <20100824233600.4A3184048C@magilla.sf.frob.com> Date: Tue, 24 Aug 2010 23:36:00 -0000 X-SW-Source: 2010-q3/txt/msg00128.txt.bz2 > When the main thread exits, gdbserver still exposes it to gdb as > a running process. It is visible via "info threads", you can switch > to this thread, $Tp or $Hx result in "OK" as if this thread is alive. > gdbserver even pretends that $vCont;x:DEAD_THEAD works, although > this thread obviously can never report something. This is sort of consistent with the kernel treatment. The main thread stays around as a zombie, acting as a moniker for the whole process. But indeed that is not actually useful for any thread-granularity control or information (well, there is the dead thread's usage stats, but that's all). > I don't think this is really right. This just confuses the user, and > imho this should be considered like the minor bug. I tend to agree, but don't think it's a big issue either way, really. > ugdb doesn't do this. If the main thread exits - it exits like any > other thread. I played with gdb, it seems to handle this case fine. Sounds good to me! > - The exit code (Wxx) can be wrong in mt-case. > > The problem is, ->report_death can't safely access > ->group_exit_code with kernel < 2.6.35. This is > solveable. Don't even worry about it. If there is something trivial to do that makes it better for earlier kernels, then go ahead. But if the easy thing to do gives correct results on >=2.6.35 and racily wrong or random results on older kernels, then we can just live with that. Thanks, Roland