From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69032 invoked by alias); 13 Jun 2016 13:49:33 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 69021 invoked by uid 89); 13 Jun 2016 13:49:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=unstable, H*r:0300, 7101, sleep X-HELO: dgw.wapice.com Received: from dgw.wapice.com (HELO dgw.wapice.com) (81.209.51.126) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 13 Jun 2016 13:49:31 +0000 Received: from dgw.wapice.com (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 83F4D1D8510_75EB9E6B; Mon, 13 Jun 2016 13:49:26 +0000 (GMT) Received: from EDB3.wapice.localdomain (unknown [10.0.4.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "EDB3.wapice.localdomain", Issuer "wapice-AD0-CA" (verified OK)) by dgw.wapice.com (Sophos Email Appliance) with ESMTPS id 5D3341D57C9_75EB9E6F; Mon, 13 Jun 2016 13:49:26 +0000 (GMT) Received: from EDB2.wapice.localdomain (10.0.4.80) by EDB3.wapice.localdomain (10.0.4.81) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 13 Jun 2016 16:49:25 +0300 Received: from EDB2.wapice.localdomain ([fe80::6505:8c2b:603d:1b60]) by EDB2.wapice.localdomain ([fe80::6505:8c2b:603d:1b60%16]) with mapi id 15.00.1156.000; Mon, 13 Jun 2016 16:49:25 +0300 From: =?iso-8859-1?Q?Lassi_Niemist=F6?= To: "gdb@sourceware.org" , "xenomai@xenomai.org" Subject: PowerPC hardware watchpoints unstable with GDB and Xenomai Date: Mon, 13 Jun 2016 13:49:00 -0000 Message-ID: <42c54218160e4143baa545e4ee994e81@EDB2.wapice.localdomain> References: <47132d04b76942d8bd15c82a5a460f7b@EDB3.wapice.localdomain> <20160403190948.GC20399@hermes.click-hack.org> <20160430064939.GC1781@hermes.click-hack.org> In-Reply-To: <20160430064939.GC1781@hermes.click-hack.org> x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2016-06/txt/msg00014.txt.bz2 Hello, I am trying to debug (applications, not kernel) using hardware watchpoints = (memory breakpoints) with=20 GDB: 7.10.1 and 7.11 (local mode) Processor: PowerPC e300c3 (MPC8309E) Xenomai: 2.6.1 Linux: 3.1.10-ipipe I have two issues: 1) If I set up a while(1) loop with (a global) counter and sleep, and place= the watchpoint on the counter variable, I get GDB to break nicely to each = increment if I use usleep() in my loop. Instead, if I use rt_task_sleep(), = the watchpoint may go unnoticed for up to 100 loops, then trigger, then aga= in go unnoticed for 5 loops and so on. Triggering happens on correct line, = though. This is reproducable with a simple C main with only rt_task_shadow = and the loop.=20 2) The watchpoint seems to go broken (at least sometimes) when new (rt) thr= eads are being created. The GDB still thinks the watchpoint exists, but it = never gets triggered. If I remove the wp and create it again, it starts tri= ggering. This finding I will investigate further and see if it is reproduca= ble with simple test code. Are these known issues? I found only little information about using watchpo= ints on xenomai, so is it something rarely used? Or is the PowerPC integrat= ion the broken part here? GDB, in turn, has had some patches on the hardwar= e-watchpoint inheritance at thread creation, so I would assume that it at l= east "should work". Any hints for debugging the issue further? BR, Lassi Niemist=F6 Wapice Oy Vaasa, Finland