From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24274 invoked by alias); 25 Jun 2008 22:12:43 -0000 Received: (qmail 24264 invoked by uid 22791); 25 Jun 2008 22:12:42 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 22:12:22 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id DC3729835A; Wed, 25 Jun 2008 22:12:20 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id AA9EB9810F; Wed, 25 Jun 2008 22:12:20 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KBdDw-0001gM-2E; Wed, 25 Jun 2008 18:12:20 -0400 Date: Wed, 25 Jun 2008 23:08:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [non-stop] 08/10 linux native support Message-ID: <20080625221220.GB5723@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200806152205.49241.pedro@codesourcery.com> <20080625201946.GH25575@caradoc.them.org> <200806252217.25796.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806252217.25796.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00459.txt.bz2 On Wed, Jun 25, 2008 at 10:17:25PM +0100, Pedro Alves wrote: > > This may be trouble. Sometimes the thread state is not > > atomically updated, so peeking at it right after creation but before > > an event can fail. > > > > Oh, that's not nice. Is this something that's worth and/or possible > to fix in libthreaddb? I don't remember whether it's fixed in current libthread_db, or else impossible to fix due to the kernel interfaces involved. There's tension between having the thread on the list early enough and having its entry be correct. I know I wrote a related kernel patch, which was never merged. libthread_db is better about this than it used to be though. > > Why is it necessary? We already know the ptid since we made them > > independent of thread_db TID some time ago. attach_thread should cope > > if the thread is already in GDB's thread list when the event > > eventually arrives. So we should be able to just add the new > > thread directly. > > That's right, the only thing we'll miss if we do that, is the > thread_db id of the thread in output like: > > [New Thread 0xf7e11b90 (LWP 26100)] > ^^^^^^^^ > And info threads: > > 2 Thread 0xf7e11b90 (LWP 26100) (running) > ^^^^^^^^ > > Those will only show up on the next stop event (of any thread). > It may take a while, if all threads are running (unless we do > momentarily stop threads trick). Oh, dear. Options: - delay the notification until thread_db discovers the thread, if libthread_db is already active - display the notification without the thread ID; we'll have the LWP ID and we could add the GDB thread number - go with your code and fix broken situations as they arise I'm undecided. Note that your code is unnecessarily quadratic, by the way. It'll walk the entire thread list; we could just load the new thread since we know its LWP ID. libthread_db may still do a walk in that case though... > > SIGKILL should work even if the thread is stopped. > > I think I'll need a SIGCONT as well in that case. For some > reason, I wasn't getting that to work all the times. I'll > experiment some more. Kernels may vary in this regard. Your code seems reasonable. PTRACE_KILL is supposed to be just SIGKILL + PTRACE_CONT, and SIGKILL is supposed to work even on stopped processes, but the details come and go... as you know, signal handling is a very touchy area and hard to write tests for. -- Daniel Jacobowitz CodeSourcery