From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103103 invoked by alias); 30 Jun 2016 15:32:03 -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 102087 invoked by uid 89); 30 Jun 2016 15:32:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=continued 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; Thu, 30 Jun 2016 15:32:01 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE31B7DCF9; Thu, 30 Jun 2016 15:31:59 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5UFVw1H006479; Thu, 30 Jun 2016 11:31:59 -0400 Subject: Re: [RFC] Set process affinity in test to work around ARM ptrace bug To: Yao Qi , gdb-patches@sourceware.org References: <1467295036-2816-1-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: Date: Thu, 30 Jun 2016 15:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1467295036-2816-1-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00552.txt.bz2 On 06/30/2016 02:57 PM, Yao Qi wrote: > Then, I am thinking we can workaround this bug in testing, because the > intermittent fails are confusing in comparing test results, by binding > both tracer and tracee on the same core. For example, we can start GDB > or GDBserver with "taskset -c 0 ", but this is a global change, may > have some affects on gdb.threads tests. > I also think about doing > "taskset -p PID -c 0" in test harness after the inferior is started, > and do the same to the parent process of inferior (which is either GDB > or GDBserver). > > The approach in this patch is to have a small c function which sets > both process affinity and its parent's affinity to core 0. This > function should be called in these tests explicitly, but other tests > are not affected at all. This patch is posted to get comments on the > necessity of workaround this kernel bug, and the proper to workaround > this bug. There are still some test cases affected by this kernel bug, > but this patch doesn't touch them yet. Pushing people to update their kernels would be better, but I understand how that's complicated on ARM, given that in many cases it's not even possible to have access to the kernel's sources... Still, it'd think that a fix in gdb/gdbserver itself would be better for _users_. Also having to manually determine whether a test is misbehaving because of this problem or not seems like recipe for continued pain. I also think that whatever workaround, if any, should be limited to known-broken kernels. Otherwise, this is likely to mask other problems going forward. Maybe all we have is the version number to work with, but that's still better than unconditionally enabling this on arm. Thanks, Pedro Alves