From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19220 invoked by alias); 12 Dec 2008 21:14:07 -0000 Received: (qmail 19211 invoked by uid 22791); 12 Dec 2008 21:14:06 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Dec 2008 21:13:18 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id mBCLDG7m001841 for ; Fri, 12 Dec 2008 13:13:16 -0800 Received: from localhost (ruffy.corp.google.com [172.18.118.116]) by zps77.corp.google.com with ESMTP id mBCLDFiY022419 for ; Fri, 12 Dec 2008 13:13:15 -0800 Received: by localhost (Postfix, from userid 67641) id 57CE01C7A79; Fri, 12 Dec 2008 13:13:15 -0800 (PST) To: gdb@sourceware.org Subject: gdbserver ptrace not doing waitpid after attaching to threads? Message-Id: <20081212211315.57CE01C7A79@localhost> Date: Fri, 12 Dec 2008 21:14:00 -0000 From: dje@google.com (Doug Evans) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00041.txt.bz2 Hi. There's something about gdbserver's use of ptrace that I don't understand and I'm hoping someone can help. AIUI, after attaching to a thread (or process) one must wait until the thread has stopped before one can, for example, read regs. [Well, one can cheat and assume enough time passes before trying to read regs, but that's cheating. :-)] If one tries to read regs too soon ptrace will return with ESRCH. This is the behaviour I'm seeing in a version of gdbserver I'm hacking on - my register reads are intermittently failing with ESRCH. If I add code to wait for SIGSTOP after attaching to all the threads then my register reads start working. However, gdb+gdbserver works just fine (obviously), and in fact there is code in gdbserver to explicitly skip/ignore the initial SIGSTOP in linux-low.c:linux_attach_lwp: /* The next time we wait for this LWP we'll see a SIGSTOP as PTRACE_ATTACH brings it to a halt. We should ignore that SIGSTOP and resume the process ^^^^^^^^^^^^^^^^^^^^^^^^^^ (unless this is the first process, in which case the flag will be cleared in linux_attach). On the other hand, if we are currently trying to stop all threads, we should treat the new thread as if we had sent it a SIGSTOP. This works because we are guaranteed that add_process added us to the end of the list, and so the new thread has not yet reached wait_for_sigstop (but will). */ if (! stopping_threads) new_process->stop_expected = 1; and there is code linux_attach to undo this because for main thread we *do* want to wait for the initial SIGSTOP after attaching to the process: /* Don't ignore the initial SIGSTOP if we just attached to this process. It will be collected by wait shortly. */ process = (struct process_info *) find_inferior_id (&all_processes, pid); process->stop_expected = 0; Anyone know what's going on here? Why the different treatment for the main thread vs the others? Why isn't gdbserver waiting for a SIGSTOP after attaching to threads? I've run gdbserver under strace and see that gdbserver is essentially doing ptrace (ATTACH), ptrace (SETOPTIONS), ptrace (GETREGS) on threads with no intervening waitpid. I wonder if gdb is working just because of luck: maybe enough packets go back and forth before gdb tries to read regs that all threads have stopped by the time gdb needs them to have stopped. In my hacked gdbserver I'm doing a register read almost immediately after attaching.