From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31345 invoked by alias); 17 Dec 2014 13:04:40 -0000 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 Received: (qmail 31333 invoked by uid 89); 17 Dec 2014 13:04:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 17 Dec 2014 13:04:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBHD4YhG024597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Dec 2014 08:04:34 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBHD4Wf4020838; Wed, 17 Dec 2014 08:04:32 -0500 Message-ID: <54917F5F.3020005@redhat.com> Date: Wed, 17 Dec 2014 13:04:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 4/5] Linux: Skip thread_db thread event reporting if PTRACE_EVENT_CLONE is supported References: <1418748834-27545-1-git-send-email-palves@redhat.com> <1418748834-27545-5-git-send-email-palves@redhat.com> <5490A306.3060002@ericsson.com> In-Reply-To: <5490A306.3060002@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00480.txt.bz2 On 12/16/2014 09:24 PM, Simon Marchi wrote: >> Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new >> threads in the inferior (to attach to them) or to learn about thread >> exit was to coordinate with the inferior's glibc/runtime, using >> libthread_db. That works by putting a breakpoint at a magic address >> which is called when a new thread is spawned, or when a thread is >> about to exit. When that breakpoint is hit, all threads are stopped, >> and then GDB coordinates with libthread_db to read data structures out >> of the inferior to learn about what happened. > > That is libthread_db's TD_CREATE event? Could you point out where that is > done (stopping all the threads)? When we're using libthread_db, the linux-thread-db.c target is pushed on top of the target stack. So a target_wait call ends up in linux-thread-db.c:thread_db_wait: static ptid_t thread_db_wait (struct target_ops *ops, ptid_t ptid, struct target_waitstatus *ourstatus, int options) { ... ptid = beneath->to_wait (beneath, ptid, ourstatus, options); ... if (ourstatus->kind == TARGET_WAITKIND_STOPPED && ourstatus->value.sig == GDB_SIGNAL_TRAP) /* Check for a thread event. */ check_event (ptid); ... return ptid; } and the beneath->to_wait call ends up in linux_nat_wait -- _that_ is what stops all threads just before returning to thread_db_wait. > From the previous discussion with you, I > was thinking that those breakpoints did not affect execution. I don't find > any code in linux-thread-db.c that would do such a thing. I think you're thinking of https://sourceware.org/ml/gdb-patches/2014-12/msg00210.html What I was saying is that although the TD_DEATH event results in all threads stopping and then gdb core resuming the target, it's not when the TD_DEATH event breakpoint is hit that we call delete_thread, so that's not when mi_thread_exit ends up called. Instead, after TD_DEATH, the thread that is exiting actually still exists and is resumed (it still has a few instructions to run inside glibc/pthread before actually calling the exit syscall), and then later when the thread actually does the exit syscall, waitpid returns an WIFEXITED status for it, and gdb _then_ calls delete_thread, all within linux-nat.c, without stopping all threads. >> This is exactly the same behavior as when debugging against remote >> targets / gdbserver. I actually think that's a good thing (and as >> such have listed this in the local/remote parity wiki page a while >> ago), as the printing slows down the inferior. It's also a >> distraction to keep bothering the user about short-lived threads that >> she won't be able to interact with anyway. Instead, the user (and >> frontend) will be informed about new threads that currently exist in >> the program when the program next stops: > > Is this a consequence of the change of algorithm, or did you actively changed > the behavior? Both. :-) I made GDB do an implicit "info threads" just before presenting a user-visible stop to the user a while ago. See the update_thread_list call in normal_stop, added in git b57bacecd5 -- see also references to local/remote parity in that commit's log. And it's a consequence in that stopping linux-thread-db.c from calling add_thread results in that update_thread_list call finding new and dead threads then. > From what I understand, gdb still attaches to the new thread as soon as it spawns > (when it receives the PTRACE_EVENT_CLONE event), Close, with PTRACE_EVENT_CLONE, gdb is automatically attached to the new clone; the kernel does that for us. > so it could print the notice when the event happens. Right, see the code in linux_handle_extended_wait that does that, in non-stop mode, only. I'd like to remove that bit soon enough though. I've mentioned before that I regret having added it. > Not that I mind, but I just want to understand. Hope I made things a little clearer. Thanks, Pedro Alves