From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36619 invoked by alias); 17 Feb 2017 03:06:38 -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 36333 invoked by uid 89); 17 Feb 2017 03:06:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=arguing, traps, corner, suspending X-HELO: sessmg22.ericsson.net Received: from sessmg22.ericsson.net (HELO sessmg22.ericsson.net) (193.180.251.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Feb 2017 03:06:06 +0000 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 61.5A.08672.C9866A85; Fri, 17 Feb 2017 04:06:04 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 17 Feb 2017 04:05:48 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=antoine.tremblay@ericsson.com; Received: from elxa4wqvvz1 (67.71.111.110) by DB6PR0701MB1878.eurprd07.prod.outlook.com (10.168.10.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Fri, 17 Feb 2017 03:05:46 +0000 References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> <2255ed6f-a146-026c-f871-00e9a33dfcf0@redhat.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Antoine Tremblay To: Pedro Alves CC: Antoine Tremblay , Yao Qi , "gdb-patches@sourceware.org" Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping In-Reply-To: Date: Fri, 17 Feb 2017 03:06:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: DM5PR02CA0066.namprd02.prod.outlook.com (10.168.192.28) To DB6PR0701MB1878.eurprd07.prod.outlook.com (10.168.10.150) X-MS-Office365-Filtering-Correlation-Id: fceffbfd-87e3-4920-c48c-08d456e1df29 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB6PR0701MB1878; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB1878;3:2B1sgXHRfP4KwkkUxGyVgRM0xnAHlbRo25coP+OQYA45LqIFZrBZ4r024y4whbf7rf2ELYfbafRi6vIqHuAG8hACQr8wi8ShMooStFzTt1mxqc8F/mqNIMaFfIqT7Le/V+2ynT81jX2eFhvoY4oEhSLpIEBuVghWX5q4OCvr8UJG5WQr+TrIYocbx/tJcwGjDZ99PNOCKMnv0sXmCbJQlp5wAo/iZlLbdwW/o7e9Osw6MT85U96XLKMV3iJgkmJ7UThcHbdq29M4W5EcdBw3oA==;25:fASTm00vooSGEK+RoxIyUoWuEiRJNnCgPegI8dpo+bZNkY9icbo1X2kT5/ZneMnp8khVINWVEl0CAUC056L45iPYj/ezEUUzNnQGZCBk+mhGizeENi2t6WASzmPQS5PctlDIzPrKFDgfVTNrEYoNUdkoAMBBe1EWLXNY1AoONf0znRzi5gupMTE056LlrzCl1gAU5E7gIYKxi7OX4o2ZReZZ8kKtg0NWs19mq1/t9Lj8TU/ZMsntU3ilfQkTzxmXscKqbrttEoA33Lk/goHoVOfAAALIWjEjtYYfinCVmYgs7SwMhrZbgzRq9UN0+gjgD5Vv5vfdq6bavMO9s1zR8//iAordGoSdTAejWP1tnoDMC9F3R1GDEu/OHHZ+HAnRyy2x2YMd3TxVfB4+PjPNaTUKGfXVspO/GRBrFZ8bTkgx266YNJHT+HJmW/dRHYdRUDAG8uUorY8xIkNWhfHOJw== X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB1878;31:QzcnSkTF0SqeThvyhVF4vaNYNEAHAq9/MPz1GZzg/RfPFBjL1aum2Bd9QheJc1UWqCp5lS9NbEBMHx0bWUlvpLqed7cvIK6/4Z/vBVRyqyB5sdxMkGUhJo2LZZZs+cxYboi1reToSjVeGMdor93IV0ThNF00XuJFAP0YKsvh/tJmTrRVp3ve0OOf7ua5JLOVuBA4A9hYUcPBipDD6YeN8k/8NcGV5+2plyeyerOshJAw06s+ucCfnuNz96qii3h/;20:m/bBzI2MvLW6Q7r0NQCNc0+O3qRH8SsIYYFennsNnN8ePMDacLFmT9e7XbUtg/Pk29qMX6YN18cwIoEIpoaXTyV+FQmfIsFRkzFRDob6evD21dh9cDTitT4Bj0j1z7iSeq4qSrHVoUzSbKV0cfIlex3luPUcyIu8e493HSKUcy/My0Z25FCQwda50hL5JVQIKGPBWdagFPYr147kcqkIInaRr1ohXvdzxHdPnnzxq1xIoyHwmWRT4acXt3SM2C5cX241V4ajnONbJ8NSZRyVKGXIjgH40Zgzakjdcvy5vVb/hp0Yi/DZe8Y/mCjAj6AF+xB9a4QXkmm3UAg3AuwiO3TcZOw2x8dv7/25hYokrPWv03lLZkBDv3UVQ5Rykmm9F/8jAT04LSBlFLwJ/haCx3ivn2OqFrdyx9/oRZ9mTxA0BIai8zFVSZPd1iF7n2CWcOhzE+EqAw31s2CQ/ij8cSgq/igvN+MoTW7IOczyqMihNKddhVfHfMvm3E6PLrOs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(6072148);SRVR:DB6PR0701MB1878;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB1878; X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB1878;4:NWMwlNnVa05wqW72c+WKExU6XwHkRYqktFDJ+k393xrp0konCrKvLUPAimRjFq2oe/R1kqM/q8SbzJUY3UUi1nUOekxO1G8v/MCHYDHKLtjIr8QbI8K09pma9/CoQ/f1RHY7XDqQOy+D35bP/ebAEieYbaikb8jgsEdpYSLmyNoPq7k3pbi/jFbYc5WZ0st9Oiggs4gJCXzuBcgqGeLKv27rP3PNCmWyQL+Nz5SOe7yjrlg/Fq99MFUm/jKzjcDjZokBsPWGcJAOQjXPrsUW96bqHMaxg2TMDpcjXJNW3FbNlToWKWKQ/H93niAonT2NJBYFOR1954C63jBKX8520Z6jyc+vGBWVMmpJLFEo3kt36adORbpe9TRW2dlx3h7wPrZJRM0DrkYRp9WlZK4Vp2da5Wq8jrIpZEUBejX74li90xMRoIZeBOVoP7JddMSLQVpgN8/NdKxzzOLhafKwYr8cIpkAcgNjGXWv4S++mpYD7D0dV27aykG4aSGtVkIoepkur0JMIWHBa7P34AQDcJ5zwA7sU2k/EjBp0qM6CuQxOuRXO4crnsXMTsoYYt6j2Y9LjJGZWbKuB4tt1ACPZ2iLhArEnpOhWYXVfFL8oLGVzVxk48KrgyjMyJ2bRGJnHkNf6rJTFGiIyOpl0//uFw== X-Forefront-PRVS: 02213C82F8 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(7916002)(39450400003)(199003)(24454002)(377454003)(189002)(2950100002)(6666003)(42186005)(86362001)(6916009)(33646002)(6116002)(3846002)(93886004)(66066001)(47776003)(5660300001)(6496005)(6246003)(110136004)(305945005)(50466002)(48376002)(53936002)(76176999)(50986999)(36756003)(38730400002)(54356999)(101416001)(2906002)(7736002)(5003940100001)(4326007)(92566002)(189998001)(106356001)(68736007)(6486002)(8676002)(81156014)(105586002)(229853002)(54906002)(83506001)(25786008)(4001350100001)(81166006)(97736004)(53546006);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0701MB1878;H:elxa4wqvvz1;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DB6PR0701MB1878;23:e7ETlUuZ5iP8yJO7PHJJ4ynKULNqJWKVxv9QdZe?= =?us-ascii?Q?PUYtwjjMiwuxvU/u5NsEw+PNxtTVlpRGOHehNNtLK48VNirSj1DBtCy4X14c?= =?us-ascii?Q?b0bvUhzDuP/29XQCBp5fF8zAHuPkxyQmqGkMGnvJXJ0FviHA6Ksq6386g2Rr?= =?us-ascii?Q?fDD5hw9pujFWYem4hzv9EaQj5hFwrQb6U3wOAYu5CbyeFIKGiL6wWioenq+m?= =?us-ascii?Q?tY4Ln1Et4J3ReVFWAwKcUDGTNgKIxQZAunQcBk5CYrxKGEEHEn7K7vch5KUW?= =?us-ascii?Q?Ut5owlUZE7gA6rw80iSd/aFcM5PrR/f8R/44aS4Y4Mi2ef/FsEglwwH20nuZ?= =?us-ascii?Q?UFrHzGZzu6kr1Go5poZEmFKH+B1H7CrcRSbg+wgyk4F0PTdNZYPFQbe6NTLc?= =?us-ascii?Q?dQH75fpoULgbnG6w+Il87teMI+/BPeBLFcIv/xIKTLcC4raGX7GfdGe/P1ex?= =?us-ascii?Q?zusYCKT2yxti30KNIayNSK+beSFXGCgrFmyJZvOOBL9G63HgCjY/lybu5Bq6?= =?us-ascii?Q?hCaet2U+BcPWSfzwKw4+ryNVjytwnYkEdLRX8JvZeQnT0tVnTfG2LSCa/+T4?= =?us-ascii?Q?8ijux9/+KNU8qMaJnna8duqhWtHo36tY055p0Rep/SH7ApQjx/e6zaWmAtqo?= =?us-ascii?Q?oIpXFBBQbiVqVmF7BTVvPSTIlZRs+G7yTGpDgeFRNbDYtQOiHZn0WK4pzkO6?= =?us-ascii?Q?BqmwNjrsmK6Y5zk3QuUFZPF6Zwi7lHute/8Yv4EFzueidpb6DBJgJGoj3bEo?= =?us-ascii?Q?ybuXxFkzyMfD1nNF5w9yShosgY07WD9kNIvJDm0mX5c2BTOkq4ZrJqeIKxf/?= =?us-ascii?Q?4VeIlSfJ3tCw3JQnmAGUTj6z/Y5DUqaI42F/TPDbHykA3CqLUeVczgfKWzzz?= =?us-ascii?Q?kyNRxIo8c6nvlAAIqN2jBxrWQgfgXEtvT6cI19pANoZzK7fRNHZ5SgSuYHq1?= =?us-ascii?Q?HxaLFq5rYcUrYYk8PA7Vg8V6BhdQHKqMCDutR+u3sXhpvShtF38ht1SFRfeX?= =?us-ascii?Q?3IR6Ki4C9eGEzIP4nkJzFiHtnAuFtmKlq6m8QLGTpyhx1VjKH0reziDLMxJU?= =?us-ascii?Q?xEFLxPbMGwW5JFvEhSea62e3KKk1G9HENFUTXGeV82nflbYOzheR2mLsaX4x?= =?us-ascii?Q?9msExipZ6yjZzg1USwp6A48qyIrRYwRRpDQtqLPPuEUHXQMoVdQxgI8FunGW?= =?us-ascii?Q?Rcra/K08NfaM6e90/QSHfdR7dhdhy/OkZ4fgklUjgMdVu/4/U6/S6QVfGTPA?= =?us-ascii?Q?oClfw1N7RYCWvCkAFIfMz7iFanAsDuza4XhFClrfW5tfQc3lkFE+4qMhvNv/?= =?us-ascii?Q?NWg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB1878;6:iA93r3ju4Nti3HBIGFE9Y4qQGnxUBqk8COhGatF8VuN0jRefM3poMNKm8iRA6yJ8dq+sMvBvGjBxeSODUxdK8Pu/X6MrtLw9EUruZXYmxkRVvGWWZffZE73i9/OjM1qrG1xswaA5/Cs+pRX9oawvjXw+5thZL7IO3zS1U4PIy/GzX0+HBPRRhlLS5/UO/4pQBsnEyvdF+OXTeML7oe3m8dSKJ6GLllsAbw1D8W9c2PadX6BJH5zvSHVC+EsZ2pMnPV2Y9CIGuDFwiR7zZcR3VUfoPpZ/LJK9geKaV4/D1F8yfTY58g5ehfi9U7Y+iK42EPQwa2E4Trl6+7kbK+LSHKzGVR4tNv5ZzKSa/c+2bfLqbiV/jKqlRxlfDqSXj2byMS900XC8LDTNC0yoR5tblQ==;5:4rb4BRAHYEAyECxvZDY0dUGqGWDH0/Zess9aOfuZoBYF2Ts7NJNdim2y/0mFDhhHrxoiB6czCTCxTmokNDRfZ//4Xvlzi6BKe6AdR+ldqlIaHpoKE2ha//I9XZV77Vnl2hY1QiyedsX0WdGIDG2BSQ==;24:syYAXhAg0qI4E+wlNiKe6zNe2iygvVY1HltRZYDTOvfSqlOQAuA1PqUUPp+zNaRzUe8riC1jP1jCZqedIr+f9nDHUdrdCaVsxe0U+reCdQo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB6PR0701MB1878;7:vrZZvLQVO9INrti4T3r2gZyw3GQB3Qlat/PTEgdiVt+Atc6UWUo5DJaUtlYiQEnzwp5r8WrxXGps8VCfkRf91AX9dw8Snkwz8USt2/IS65nFDfozjYknFnAMep1PgKJA6eujJ9zEAvefDShtawX/t2sXK3G6hH44EVVqGcWf0ffRlc6RczJWzFuC3T8gH7RJGgZk4owdrT/pCry13to3JZbzdUvB/0HzFfzk511wPbRHezhYG3Jl+QXkrJf8XlYgUHMdEv8BoRquKO4Y/BflHPmJdUJ2BTSMTOjb7ewRcTUsDfoXY9rB/4IZ8+8sI7z8hOCb6ATsL1TF/TcNogRSKw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2017 03:05:46.7450 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB1878 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00465.txt.bz2 Pedro Alves writes: > On 02/17/2017 01:41 AM, Antoine Tremblay wrote: >> >> Pedro Alves writes: >> >>> On 01/30/2017 01:28 PM, Antoine Tremblay wrote: >>> >>>>> We don't change anything when setting breakpoint inside IT block. >>>> >>>> Well that's a problem if we write a 32 bit thumb2 breakpoint aligned on >>>> 2 bytes like discussed before. >>> >> >> Sorry for the delay I just saw your mail... >> >>> Can we restrict the stopping-all-threads to the case that >>> needs it, only? >> >> Possibly but I would like to avoid introducing 2 execution paths in the >> run control, it's already hard to follow as it is and it would introduce >> a lot of code in the arch independant code just for this case, that's >> something I would like to avoid too. > > I don't immediately see how this would imply introducing lots of code > in the run control. Well lots can be debatable, but at first glance you would basically need this current posted patch + what it removes and a switch between the 2. And I'm not sure how the IT block detection would be done. It just seems like much to me, I'm actually very surprised that you're suggesting having those two paths. It seems like it creates much to maintain to support this particular problem with the ARM breakpoints. Maybe it's just that I had such a hard time getting all that run control right, it's full of traps and corner cases with all-stop/non-stop, stopping, suspending, deleting the breakpoints, re-adding them at the right time etc... Adding more state is giving me quite a headache. > We shouldn't be imposing this stop-all-threads > on all archs, since it adds a lot of slowness (and > the more threads the inferior has, the worse it gets). I would be the first the agree usually that's something I would like to avoid but considering that it was crashing the inferior in the only architecture using this, not stopping seemed less important. Also I'm not arguing to keep it like this forever but until there's a better solution to the problem it seemed reasonable to me to take the performance hit. And I was pretty much certain that before another arch uses this we would have figured it out. Is there another arch on the horizon that would use this ? >So if > we already need the 2 execution paths, making the condition that > determines whether to pause all threads consider more state > doesn't seem to add that much complexity to the run control > part itself. > >>> An optimization that would avoid this would be to use a >>> hardware watchpoint/breakpoint (if available) for single-stepping. >>> IIRC, you can ARM a breakpoint (or was it a watchpoint) on ARM for >>> triggering when the PC is different from the current PC (or really, >>> some specified address). >> >> I did not know that but I'm worried about the limited number of hardware >> watchpoints available. IIRC on my board I had only 4, if GDBServer can't >> find one available would it refuse to single step ? That would be >> weird... ? > > My thought was that we'd give preference to user-requested > watchpoints. I.e., treat this as an optimization. We always need to > pause all threads in order to install watchpoints in all > threads (watchpoints must be inserted with the thread paused, and > we do that on thread resume). So if a request for a user-watchpoints > comes in, we'd just interrupt the current single-step as we currently > do, install the watchpoints, and go back to single-stepping, if it didn't > manage to finish, as we currently do. At this point, we notice that we > don't have free hardware watchpoints left, and fallback to do > the slow software single-step as before. > OK I see. Interesting. >> >> It's an interesting approch however I'll dig about it more. >> >>> >>> In IT blocks, this would probably make the thread stop on >>> instructions that aren't really executed (e.g., the then/else >>> branches when the condition is correspondingly false/true), >> >> Really ? I need to find something about that in the arch man... > > AFAIK, in IT blocks, all instructions always "execute", but, when > the condition is false, the instruction becomes as-if a nop. > The only reason breakpoints don't stop there currently is that > breakpoints are just another instruction (actually an undefined > instruction the kernel is aware of, that causes an undefined > instruction exception that the kernel translates to a SIGTRAP > instead of a SIGILL), and when the condition is false, the breakpoint > instruction becomes a nop too... If you have a hardware trap > set to trap at such an address though, then it should trap, I believe, > as if you had armed a hardware breakpoint to trap on the address > of a real nop instruction. > Seems to make sense :) I'll test it out with a hardware breakpoint. Thanks!, Antoine