From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17449 invoked by alias); 24 May 2009 03:14:34 -0000 Received: (qmail 17441 invoked by uid 22791); 24 May 2009 03:14:33 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 24 May 2009 03:14:28 +0000 Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id n4O3EO7d026305 for ; Sun, 24 May 2009 04:14:24 +0100 Received: from localhost (ruffy.mtv.corp.google.com [172.18.118.116]) by wpaz29.hot.corp.google.com with ESMTP id n4O3EMnA014331 for ; Sat, 23 May 2009 20:14:23 -0700 Received: by localhost (Postfix, from userid 67641) id C486F846C2; Sat, 23 May 2009 20:14:22 -0700 (PDT) To: gdb-patches@sourceware.org Subject: [RFA]: handle_extended_wait: Call linux_resume_one_lwp instead of ptrace Message-Id: <20090524031422.C486F846C2@localhost> Date: Sun, 24 May 2009 03:14:00 -0000 From: dje@google.com (Doug Evans) X-System-Of-Record: true 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: 2009-05/txt/msg00527.txt.bz2 Hi. There are some things that linux_resume_one_lwp does that either all callers of ptrace (PTRACE_CONT) should do (check errno) or would be nice to do (print a debugging message). I was thinking of splitting linux_resume_one_lwp into two, but since the newly created thread is, well, new the rest of linux_resume_one_lwp is a nop; so it seems reasonable to just call linux_resume_one_lwp for the new thread. It's also nice to have all calls to ptrace (PTRACE_CONT) routed through one function. Ok to check in? [tested on amd64 w/ --target_board=native-gdbserver, no regressions] 2009-05-23 Doug Evans * linux-low.c (handle_extended_wait): Use linux_resume_one_lwp to resume the newly created thread, don't call ptrace (PTRACE_CONT) directly. Index: linux-low.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v retrieving revision 1.103 diff -u -p -r1.103 linux-low.c --- linux-low.c 24 May 2009 01:09:22 -0000 1.103 +++ linux-low.c 24 May 2009 03:00:53 -0000 @@ -295,29 +295,32 @@ handle_extended_wait (struct lwp_info *e new_lwp = (struct lwp_info *) add_lwp (ptid); add_thread (ptid, new_lwp); + /* Either we're going to immediately resume the new thread + or leave it stopped. linux_resume_one_lwp is a nop if it + thinks the thread is currently running, so set this first + before calling linux_resume_one_lwp. */ + new_lwp->stopped = 1; + /* Normally we will get the pending SIGSTOP. But in some cases we might get another signal delivered to the group first. If we do get another signal, be sure not to lose it. */ if (WSTOPSIG (status) == SIGSTOP) { - if (stopping_threads) - new_lwp->stopped = 1; - else - ptrace (PTRACE_CONT, new_pid, 0, 0); + if (! stopping_threads) + linux_resume_one_lwp (new_lwp, 0, 0, NULL); } else { new_lwp->stop_expected = 1; if (stopping_threads) { - new_lwp->stopped = 1; new_lwp->status_pending_p = 1; new_lwp->status_pending = status; } else /* Pass the signal on. This is what GDB does - except shouldn't we really report it instead? */ - ptrace (PTRACE_CONT, new_pid, 0, WSTOPSIG (status)); + linux_resume_one_lwp (new_lwp, 0, WSTOPSIG (status), NULL); } /* Always resume the current thread. If we are stopping