From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92578 invoked by alias); 22 May 2015 18:55:41 -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 92258 invoked by uid 89); 22 May 2015 18:55:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS,T_FROM_12LTRDOM autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 May 2015 18:55:38 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1Yvs6Z-0003dZ-Sr from Don_Breazeal@mentor.com for gdb-patches@sourceware.org; Fri, 22 May 2015 11:55:35 -0700 Received: from build4-lucid-cs (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Fri, 22 May 2015 11:55:35 -0700 Received: by build4-lucid-cs (Postfix, from userid 1905) id 36DA040E8F; Fri, 22 May 2015 11:55:35 -0700 (PDT) From: Don Breazeal To: Subject: [PATCH 0/3] Extended-remote follow-fork cleanups Date: Fri, 22 May 2015 18:55:00 -0000 Message-ID: <1432320931-1550-1-git-send-email-donb@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00613.txt.bz2 This patchset addresses a few extended-remote test failures discovered by the buildbot and noted by Sergio in this email thread: https://sourceware.org/ml/gdb-patches/2015-05/msg00372.html Several of the failures were expected. These were in gdb.base/foll-vfork.exp and depended on exec events, which are not yet supported for extended-remote. I had mistakenly concluded that a couple of other failures were due to the lack of exec event support. One of these was due to the remote interface printing a thread identifier instead of a process identifier in the follow_fork verbose mode "Detaching..." messages. The other was more serious, where a vfork child could sometimes be (incorrectly) resumed when handling the vfork event. The patchset addresses these three issues with the following three patches: Patch 1: modifies the ptids used in the verbose-mode "Detaching..." messages in infrun.c:follow_fork_inferior to ensure that they print "process nnn" instead of possibly "Thread nnn.nnn", so that native and remote follow fork have the same behavior and match what the follow fork tests expect. Patch 2: initializes the threadinfo.last_resume_kind field for new fork children in gdbserver/linux-low.c:handle_extended_wait. This prevents the event handler from incorrectly resuming the child if the stop event that is generated when it starts is reported before the vfork event that initiated it. Patch 3: disables the tests in gdb.base/foll-vfork.exp that depend on exec event support for gdbserver targets. Tested native, native-gdbserver, and native-extended-gdbserver on x86_64 GNU/Linux. Thanks --Don