From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23867 invoked by alias); 26 Jan 2015 17:19:31 -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 23764 invoked by uid 89); 26 Jan 2015 17:19:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,SPF_HELO_PASS,SPF_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; Mon, 26 Jan 2015 17:19:23 +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 t0QHJKct004783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 26 Jan 2015 12:19:21 -0500 Received: from brno.lan (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 t0QHJJ1i011197 for ; Mon, 26 Jan 2015 12:19:20 -0500 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 0/3] Fix racy FAILs of sigall-reverse.exp (and more) Date: Mon, 26 Jan 2015 17:32:00 -0000 Message-Id: <1422292759-22307-1-git-send-email-palves@redhat.com> X-SW-Source: 2015-01/txt/msg00706.txt.bz2 As can be seen in the buildbot results sent to the gdb-testers@ list, sigall-reverse.exp is occasionally failing. With my WIP all-stop-on-stop-of-non-stop series some other tests were failing in a similar manner, which was what prompted me to look at this in the first place. This series fixes the root problems. sigall-reverse.exp seems to be robust for me now. Tested on x86_64 Fedora 20, native and gdbserver. Given the 'query' change that exposed these bugs is in 7.9, I'd like to see this fixed there too. My idea would be to push this into master, give it a few days of buildbot exposure, and if all goes well, push it to the branch. Pedro Alves (3): Fix up some target is-async vs can-async confusions When disabling target async, remove all target event sources from the event loop Simplify event-loop core, remove two-step event processing gdb/event-loop.c | 336 +++++++++++++++------------------------------------- gdb/event-loop.h | 5 +- gdb/linux-nat.c | 16 +-- gdb/record-btrace.c | 17 +++ gdb/record-full.c | 32 +++-- gdb/remote.c | 16 ++- gdb/top.c | 1 - 7 files changed, 157 insertions(+), 266 deletions(-) -- 1.9.3