From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52993 invoked by alias); 27 Mar 2017 13:28: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 52948 invoked by uid 89); 27 Mar 2017 13:28:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_PASS autolearn=ham version=3.3.2 spammy=stuck, Hx-languages-length:4491, sk:antoine, finishes X-HELO: sessmg23.ericsson.net Received: from sessmg23.ericsson.net (HELO sessmg23.ericsson.net) (193.180.251.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Mar 2017 13:28:35 +0000 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id FD.3D.23528.28319D85; Mon, 27 Mar 2017 15:28:34 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 27 Mar 2017 15:28:33 +0200 Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=ericsson.com; Received: from elxa4wqvvz1 (192.75.88.130) by VI1PR0701MB1886.eurprd07.prod.outlook.com (10.167.197.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 27 Mar 2017 13:28:30 +0000 References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20161129120702.9490-2-antoine.tremblay@ericsson.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Antoine Tremblay To: Yao Qi CC: Antoine Tremblay , "gdb-patches@sourceware.org" Subject: Re: [PATCH 2/2] Avoid step-over infinite loop in GDBServer In-Reply-To: Date: Mon, 27 Mar 2017 13:28:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: CY4PR12CA0034.namprd12.prod.outlook.com (10.175.82.148) To VI1PR0701MB1886.eurprd07.prod.outlook.com (10.167.197.22) X-MS-Office365-Filtering-Correlation-Id: 6443d8a3-003e-42a5-c4c2-08d475152979 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR0701MB1886; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB1886;3:ovFPunCQsxQ3X7H5m8Lqre1iTB+tvX99Zr4EvpMu8750IMp+p+Fbo1jZ98ccxq/X7C/kQ2tgLvRV071PgYb9r4A6xhSpsxTId1ixE2T8piAKaR1BnPMkBCChYuorUw7NCkgOBWWOb1R/Bsov+U9I04xP7CuNmSjtVyj17D0G2av5mleByOfvFftGxK35clz+ouHC8jy2+fHqMv5pkzGReYziF6e5VvKSA9zpkxUCyRZlBWf861B6EX/GDTewnR9ki6FxM36kIR+fWDrDtP7pdA==;25:leQIkpvQBNjD05o3NS3/28704P2PmOHxwRXZsMNaTTwrRxvXEAYeJjyvCjkxS/5jXx+RVt99OT/1RcBUKLu1j6X4KqmALyGEiYCZaMOAk9ukXmuCMhw6QkWUZB3ZEI9UgKx3bSsNIQvSU1nkk6SIwEdC8WK3cHqUCD2vLM0HQmbPAjS2wVGeD+QanGEKqMkpzCjSfi25l7wHO8o4KJ62YEZboGh7I84n0EZvJVkTg8zWVxauHWnfpuOWDpzlrtokEfDccFGemjXjn5dTpLbkgZVWC/YrvKKnO88p8bMhssjikK32W1qrkhgggSG6qrPZwFowccr1aK+k62TWF+uDC6U1UWp6swI9pF6MDUWIftmW62+n2Im1okpmD5RI+cR7gBoMTi/dHtRx8x3W7rrsVRK22s9bsofq/ibZ+QSUgrTzX1GUwpRwf5P5c76mCReJViKigm0uped0U3csWtSvpQ== X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB1886;31:ChlclnTagx5eO5Bd+J94cMyRd4qzkDDxcaNh+ZyW4rRmwvcq/Viejkn3kGZC93VLuvHbZt1kvE+LmvfuwErq+X0VoAiwEkXpqsHPptSjGXvjvulwQ2+5knIG7l0+PerVjSOcCWdOosJd/nMqgbTRCzVggLRA7lM7yIAzCkvGr+JE9b/S3xWAn7A2LCeSmgT+nTBmn7CSeUEDkWoDTaSYj+sql1naj7gj1YWaDUAWOYo=;20:g3KGpLrIWiEO8BlJOhGy8jDwM8P7sVAKRcGx/+VoN2nQ1dabG9KCTg7agA1LS1q3JhNnq42dYAhZ61mPHisae2IQZZAlSnqwtC9NisfMzYRpgzcA/+g1sd4jipCIUYqUb2L9nn4tCxmcNQG1Qm+vhzKgoZzW1KpRr0p8Os5e8dJhKvpgh7y2QQJRoj6hMl1HUCGqTspWj2xso3mj4sHrH9FNwNC3YtxCoY6xyLF3uogZZfMkNR8UjPebViCltCGnMav0RCjgR9KR7LIilY3XQoalewHLWv5dtM5U5WXHA7hntT7sPYQEzPbapd0+u4Xwr9gUUT1PdJrfWaF2n+4TEerK+0JTmSyOHw2JkdIGoYnihrKy2Xc/2ETxkmPDyiPl5AjqJ8VgtQ7T0dJjbo2c6fs+Qs58RCqEE6EhjmHnyDMRmLImu2zM7k05jLbg19/ejcwuNn3zb+N79l+XPzBKOTJVHvA4j8m7ApZWKMUoutoR66yrVNu9kCsX3b80R1iu X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(6072148);SRVR:VI1PR0701MB1886;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0701MB1886; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB1886;4:zswXtJimOK8YpDSapnTxm4aTs8Oy8ltjRL3FX6H35RbBhQtvZCOiiG51ZPBbdRThhuvcOGmeJPXjgqJxV2oUinBukHrQeLNV2YjT/OBufKat6A37a+z1nDn96c3g4W/pLQ/y+q2RbN9H5wbV6fF/uKb42qJ9EliajYOLLMlZfZq0Omf+DKrpbOanC2EVmnPju9wgykEcLQ5w6Rd1f449i1QDuvJe7FculFrxCDMDsakFYLvspz35T9qpEtG4KJ8ps7YFxMqgd7TgHdUpUqQWqFtaNVVtk22lSOuI61iZ+W8lyqGbPG7/aJBF96XJ71Ozz52JDr/8rwHd4frNvBDApkwCuM2WZlgqnTYTVv1RT3JNmEt5YfM8IaavGVLSNpIs/rvx9LcEc40pfHEuUojiijlp2newe+zHYJUYebOKpRNYNJ7Eiaqv/49h0K14Wls7lg8v/knX82ht61/RhcXMUWpUPHVWDxaJqoTlD6dj+uvoIYHe3HMzvRgc669BmQVlevUwdC2hzVhh0N7GD9zro6Pq4edO1FyqViPWRKEfOnTPPlWQ+MerKQJyVRrJ53AFfPTJ1uj/STPj1q+YSh7mK4i0M6nsNb1Qb7erOFvXHa2L+1x4T/hgasb3EUc56NpfaCBFnRU9jDbGT2vglRdwlQ== X-Forefront-PRVS: 02596AB7DA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(39450400003)(39840400002)(39850400002)(39410400002)(377454003)(24454002)(229853002)(4326008)(54356999)(76176999)(50986999)(47776003)(5003940100001)(25786009)(2950100002)(66066001)(6916009)(6666003)(3846002)(6116002)(33646002)(8676002)(42186005)(54906002)(53546009)(81166006)(6486002)(48376002)(189998001)(1411001)(53936002)(83506001)(7736002)(2906002)(6496005)(86362001)(6246003)(36756003)(305945005)(110136004)(50466002)(4001350100001)(5660300001)(38730400002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0701MB1886;H:elxa4wqvvz1;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;VI1PR0701MB1886;23:lUzoVKXEyicttjdL6mXc5uGdcrtHlFvVcuH5ao/?= =?us-ascii?Q?B4dC+L59M9U6bONZ5Ve6fr/S8xtc2LuC2Jdl7J949FtvTOjbtOcrp5UBeXgg?= =?us-ascii?Q?mzXVT9+4NnUwPxveHdxMLMLwE+cKoIOz6nGlimNgfLj2ORoftn31nIckg/dT?= =?us-ascii?Q?ODHZKVAx/Kh5Fim7LovmtrLv6EnT+npan8gzBQZyiET1v/k+i39qOpRW1+Pv?= =?us-ascii?Q?M7LtQTrWfH0zU+gH9RX6+6HXu5bHdc+EBQ6zsu2TerjE3CG5P7FM90E8aaMi?= =?us-ascii?Q?5KdzYvoCqEWh+dADIbuI7OR7n1qqV++KjF5ELumqHJqwcR7GJQe8XfrANLMA?= =?us-ascii?Q?eHJ33Aa4WvmIGSO7cSxRZi+TbxwsVXzYLuzAikciu+Fe5Lm9p+p/6W91Y230?= =?us-ascii?Q?7Y0a32Ybk75SBsagJYFcPMCvCRJK+6/J9oVj7TpN0W2f/zDrZhx+Gb7UaBtG?= =?us-ascii?Q?+CH5yV94qIdraAYWKagyx+IPQVjIp3U5JebIHgbzAiGqare4EihkV/vNCHGa?= =?us-ascii?Q?cP3GURa90niDcwnYeMdZgsu3TS52w8lRBtTUuFnz0JEXIaeVa/w7zxYOnUI9?= =?us-ascii?Q?GPEC/WM3wUspkLlvGjbJZoKxtQMqC8nK/a711sTrpjClrC1kkSQUEqWitkS3?= =?us-ascii?Q?lZSivPYCHfbvD//C0qZ4qNsQMZoQTY3teilrgZqZFS6/6lvwM3w/UnNkiYkf?= =?us-ascii?Q?nFZP3n6CNrXaUYTeuQJl8Cs1Qt/xGfpvDxp5eZ2YqTtjQvLXY6tzbRTQQydn?= =?us-ascii?Q?LFDjDawISFW0kvg1WeZvIJTeg40c82RoNpNLYAQGUPaBA4Nc3Zcu43SYUNfC?= =?us-ascii?Q?vGBsVZLFjkFsI1q6a3rhaMKLqPoBziAQo/Bt8vRZasM3P5mJm9A1hNKbSaJC?= =?us-ascii?Q?5d5nYv/4Kvk0GvdRpT72fmIoriWBMv9F5+KURfORsFPF4q9eK4F5Dq3noJtw?= =?us-ascii?Q?3SaEZPAvCxQ/K+8mk2C6ngvs53SvUAPG2wGxy5vC8sMnvYdd8n3hXbG1OLey?= =?us-ascii?Q?yGpaD4lzIi7pqmbP9vobxHe6UzQgqiqUbyInWqEULc1xbjXd4XcKlLh6wGnZ?= =?us-ascii?Q?z8ovwSW7eLDLJ95CvEhSMYp0S/eeN9NXQ5SGDD9KbtMu8+DApOx8nsX6KNtn?= =?us-ascii?Q?NRNT8H8IN94aKyELURMnt6N7X4lmG7BL9698/FRoopWQyz0Ehbuku0Q=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB1886;6:P/DiNU12rhv5cjh7fMoalWW3uq08+Uek009rQnuXU+FjUOph5kMmpVvDgdxPFFqfAk9/4mW0Bmq/v4r2lgFcG1e3S7bcuBTgafTXCY50UQl2Bv0QEFn9QhrYNYBcjHLDEPAEMt8RoghezmVh9H3wawNFtiiZRLqY3Xi0BjZj6kcbjsVQSFgLjdm6D9W6wYejRP+BWJc14Cz7z17226dNVwoN4/B3orrcsTQi8Mbc3ZRwR7YSFnc+VZGkMq3euoQlAya+tLDcasB4AbCvGiXsScq1vlQOxDEqI4HRwc4oMi+n8Fj5SUvXDTghilJfirtM/Qcz7FHthCIRlzVGIYPZU4Ya7r9Hab0c7p3pZhUPWL01BLDXuk9y/y9ifv7lZ9cy4DGF7Mtt7QPM0ZvduXKvKg==;5:oGq/ypK5Y5lRKs9LVh/jKloDgc9pbnUCRGBO8knzb2hBqptPsoB4pQEkSZJi/IvHZpUW+XIVdCC3KSo71jXnfmNO2+rau4lmGncUMsH+j21VCH605qKKIg4BCGBAFU2EuC/8bNtHPL1PT1TBNjnLug==;24:IwA7F58YuB2BZFYQOGOfASAL2RavdT0F6sA1hZ/I4KzE+V4oIDdCgXMgCEr//vk5gbleeHbMXzmKBuRxQWptarbD4XPBqQzP2N04q5AvOyI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0701MB1886;7:aYHR35O7ncQjbGoLPKIiw78Pib1jARfXDnp2OwxoyK/df8j86zvoshsY5EhKah7Jh6UkZvOasU/myUt6xYZFgsZnXkdusiz1lDUJzvoUpPD+EEUKswaoea/GdZWpf+zIHPN7aFBhoPnc//pb9KzuN/1z3zUgfR0tXEWP2DpL7mU5IAVJy8AYTequYYcYhQQ0frYdWTJ31m6wfFLqUIJMs8GeiVhd6MTl6mWfzUuhdmudzrLNmQJhobySlIkYXQ0mM3WoeNgIpMqq5pQ+2HPCf2Kpj5ofE60c5ptEjLqW0IWt1API5O+8pNT9BB4ht+zqoVmpCONEL95/oj78LQ0jqw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2017 13:28:30.6691 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1886 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00463.txt.bz2 Yao Qi writes: > On Tue, Nov 29, 2016 at 12:07 PM, Antoine Tremblay > wrote: >> Before this patch, GDBServer always executed a step-over if it found a >> thread that needed one. >> >> This could be a problem in a situation exposed by non-stop-fair-events.exp >> where the code and the breakpoint placement is like so: >> >> instruction A : has a single-step breakpoint installed for thread 1 and 2 >> instruction B : has a single-step breakpoint installed for thread 3 >> and is a branch to A. >> > > Is instruction B following instruction A? Is it like > > .L1: > nop > b .L1 > Yes, assuming A is nop an B is b .L1. I reduced it to that from the real world case in non-stop-fair-events.c with : 0x0000000000400767 <+38>: mov 0x200963(%rip),%eax # 0x6010d0 0x000000000040076d <+44>: test %eax,%eax 0x000000000040076f <+46>: je 0x400767 And a single-step breakpoint on all instructions. >> In this particular case: >> >> - GDBServer stops on instruction A in thread 1. >> - Deletes thread 1 single-step breakpoint. >> - Starts a step-over of thread 1 to step-over the thread 2 breakpoint. >> - GDBServer finishes a step-over and is at instruction B. >> - GDBserver starts a step-over of thread 1 to step-over the thread 3 >> breakpoint at instruction B. > > Why does GDBserver starts a step-over again? is it because > need_step_over_p doing checks like this, > > if (breakpoint_here (pc) || fast_tracepoint_jump_here (pc)) > { > /* Don't step over a breakpoint that GDB expects to hit > though. If the condition is being evaluated on the target's side > and it evaluate to false, step over this breakpoint as well. */ > if (gdb_breakpoint_here (pc) > && gdb_condition_true_at_breakpoint (pc) > && gdb_no_commands_at_breakpoint (pc)) > { > if (debug_threads) > debug_printf ("Need step over [LWP %ld]? yes, but found" > " GDB breakpoint at 0x%s; skipping step over\n", > lwpid_of (thread), paddress (pc)); > > current_thread = saved_thread; > return 0; > } > else > { > if (debug_threads) > debug_printf ("Need step over [LWP %ld]? yes, " > "found breakpoint at 0x%s\n", > lwpid_of (thread), paddress (pc)); > > /* We've found an lwp that needs stepping over --- return 1 so > that find_inferior stops looking. */ > current_thread = saved_thread; > > return 1; > } > } > > there is a single step breakpoint on pc, and it is obviously not a > gdb breakpoint, so 1 is returned. > Yes. >> - GDBServer stops on instuction A in thread 1. >> - GDBServer is now in an infinite loop. >> > > I am wondering can we take the information that we've already step > over a breakpoint for thread A into need_step_over_p, if we see pc > is on another single step breakpoint for thread B, don't do step over. There's 3 parts to consider here: - What to restart ? My first thought with this was step-over the other threads that needed to step-over in a queue like fashion, but this may not be enough since we may depend on another thread to be able to make progress on the single stepped threads like is the case in non-stop-fair-events. So like this patch does I though it was better to restart all threads... - What does it mean to not step-over ? The don't do step over part is more tricky then it seems since let's say GDBServer: - hits a breakpoint on A with thread 1 - doesn't step-over and restart all threads - any thread hits the breakpoint on A At this point thread 1 has already hit the breakpoint on A even if we do not allow it to step-over, so it's stuck there and could hit the breakpoint a number of times, thus breaking the breakpoints/trace frames counts and maybe some other stuff... I'm not sure about the solution to that, ideas ? How to "undo" a breakpoint hit ? Or some other solution... - When not to step-over ? After some thought I think we could make it so that we expect the single-step breakpoints for PC to be hit in the order of insertion. Since the breakpoints are already a linked list we could make it so that if you hit a single step breakpoint and that this breakpoint is installed on multiple threads then single-step only if the thread stopped matches the thread of the first breakpoint for that PC. Otherwise continue all threads. I think this would be simpler than to record the last executed step-over for all threads and check/reset that flag so that all threads wait for each other, but that may be possible too. WDYT ?