From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74439 invoked by alias); 10 May 2016 13:29:57 -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 74339 invoked by uid 89); 10 May 2016 13:29:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Antoine, Tremblay, tremblay, management X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 10 May 2016 13:29:43 +0000 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.58.03614.512E1375; Tue, 10 May 2016 15:28:53 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 May 2016 09:29:17 -0400 References: <1462530736-25117-1-git-send-email-yao.qi@linaro.org> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Antoine Tremblay CC: Yao Qi , Subject: Re: [RFC 0/3] Use reinsert breakpoint for vCont;s In-Reply-To: Date: Tue, 10 May 2016 13:29:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00166.txt.bz2 Antoine Tremblay writes: >> I tried different ways to remove reinsert breakpoints in GDBserver, but still >> can't fix fails in gdb.threads/schedlock.exp, that the program gets SIGILL or >> SIGSEGV. These fails can't happen in every run, and they are disappeared >> when I turn on debugging output in GDBserver. I suspect they are about the >> improper management to reinsert breakpoints. >> > > I'm not sure at the moment but this makes me think of an issue I sent > here: https://www.sourceware.org/ml/gdb/2015-11/msg00030.html > > Actually thanks to a good discussion with LTTng maintainer, (Mathieu > Desnoyer) last week I got the hint that this could be due to the > situation described here: > https://community.arm.com/groups/processors/blog/2010/02/17/caches-and-self-modifying-code > > Short story, the instruction cache could be out of sync after we've > removed a software breakpoint and the processor would execute the > breakpoint instruction causing a SIGILL rather then the original memory. > > The solution however, calling __clear_cache(...) requires that we're in > the same process for the memory addresses to be valid, I think, so I'm > not sure how to fix this yet... > > I'm still early in my investigation but it may be something to consider. > Note I tracked that down to __flush_ptrace_access in the kernel, and tried to hardcode the instruction cache flush (Thanks to Will Deacon for the hints) but that did not help, at least on the odroid ux4. Not an easy problem, I'm installing your patch series today and I'll start checking it out in more detail. Thanks, Antoine