From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73661 invoked by alias); 25 Nov 2016 13:35:35 -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 73633 invoked by uid 89); 25 Nov 2016 13:35:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Nov 2016 13:35:23 +0000 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 03.74.03096.91E38385; Fri, 25 Nov 2016 14:35:21 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 25 Nov 2016 14:35:02 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=antoine.tremblay@ericsson.com; Received: from elxa4wqvvz1 (192.75.88.130) by AM5PR0701MB1873.eurprd07.prod.outlook.com (10.167.216.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Fri, 25 Nov 2016 13:34:59 +0000 References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org> <20161121120822.GA28605@E107787-LIN> <20161124215510.pbsobdtj6niycjhd@localhost> User-agent: mu4e 0.9.17; emacs 24.5.50.1 From: Antoine Tremblay To: Antoine Tremblay CC: Yao Qi , Pedro Alves , Subject: Re: [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s In-Reply-To: Date: Fri, 25 Nov 2016 13:35:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: BN6PR02CA0072.namprd02.prod.outlook.com (10.175.94.162) To AM5PR0701MB1873.eurprd07.prod.outlook.com (10.167.216.22) X-MS-Office365-Filtering-Correlation-Id: efa0ea0c-e3b7-4966-50c6-08d41537da90 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5PR0701MB1873; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;3:FKNyur04TK35Vw64mM3mR0IxGlN3Mn2sAlkA27GqtrtSbecSEAjIHkIbLRsmPl4fYcAqsU/V4Dm1jq96IACAlFjBxFyS5VnqgL/y8NJ2DM1icKk+NdVyC4p/ChnlYMI9CxcK+GwZTLZYlmHcp9a9pot0j7rmE+PG1wijWDfJXEb7poEQxTZFwyRQ/VpJaj6Y7cTNJ3A6Eh6SNoNG60clBJWag97N7HXi7cFlXNMN9rWUa2c5INTDf3GWWaI8+sAF6a+Oeh8VkOc3OHjST+tJbg== X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;25:Hp28mfTEfnGSWhovioK+Im2XmCbwgLaA9syRhujQK3dogZg5sh8RmPuIUXApDbxV5aGq6qBMRbbs0PxwtSPm5JSAJIdUXB2AqZDWSsmgfEM6anXIJF/FDAHgevdm/oGpX26hvkFBZrJEoCJ2zMNtUEydKP1n7eVMG1VMItTq3+R9pHMmep0az9FqsG9tUJgCUHyVclPhRT0+HfZnZzJIDXtJjqATQuo2q6E8xHEvod/HRTcrg0Gclu5mjTjXpt0xLF3PVxmoH3fdeo163nWGUlqfBSHyxKPwGI7W1Ar0p6Gl6Izuu7YbtxbH6jqUO/SjRCwm2dB6+eT5KB4MIAu8oYup4kj1AZTdZ+JsMQSW4WeBforl1+loUi3nqx4MaoyPfa6YFdiEH5GOWlfFwvULSzN69YtjJp8FnnzPlF0xDn3gKUad6KdzgW7oddjj+9x7rjXqkabczGnfKy26qayOP1zV6E4oFUlS1QPso0vbg9Ad4twVyB0Bn8peWX4ldzqNo2mVfa+BUfgQw7l9XyBhyqrpkqQ8FLNpTukdqB5FyZLZcTh5d+SBL8DYqwjA1QAuLIvTRlIDodV4WDUQdRc5VGXD+HI2THiioZZl8OZYCfpDYZ/XFtX5uGOH8IqV/RipXoMxSwZ5Jz10Sz9+mXMHwIT6sWfR6YdRGsPfoY4ZgBgGL8DBvVnim4cwZ1U/wUwcJ9cRHOWn1Z5NlTHV/PnXE8q6xEMKFZu3qYQvIIOxsItHMVFVRFLQmrHVfWdBOgltz+hhCLaKl9rlLHFOaImtcVyjlWO7yXImDpeHKbUGaDdnIjA06ZTRZppvaUBUig78b/g1mECs0DdT/N32D0Y3uPzgAuzDIOTBRNvEADEBwas= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;31:ucFWnkO/o+S5BVnieUCIrvSIxmpzJu01FR80MCqdrut3wleiuXP3bclrcZB2wIoLYLnnCKkT8k8mqBXUMTYtlwV/b3pC19wG0TxGShX0KQL4z1teXmO296QtlkWbzXD7ORBZbznr0DKOUCd1bMHJPThzEOSvAAB9z3J+X+wkMTYRSEC+PF8votQMXJav3q35rHhvTrOaUZNu1P4bO3pQRUd1+cfV0KroEvwOSTogI9Fp3hUtlTpiOAagQHPpbKmfS8hmSV1893HYUba/dXA9Zg==;20:vCyGnzpF1h3b51M7y5IRnvJ60RECpMNQRzSWCc9XWixOeUmRnYg6dM0DfvcL7fkM6ntT8tkgYBTIkUBSq2MNQ7yorPvjXs1vtBPM3pggODUrbiSh8B/Os3dvHLXYMis7BiFSuforn/sCNHCpOr4218MfjDUPHfa/s5iXAZsO1Qawh1RrxKYK68+H13RoKa7dun4UecJY1/amrOVc59ChHOYra9hkx3bDM8AoZ8GeWkzTuo2QA8cSjGSa5kdXksvUUKsk6JSaFKxRjs52VIS1Yn/z8rr6fIZWtdUVMc4T3obdTMz0Lnz3IQMrrBs7TcJL8gCka5kHyulrYD4HEwc5t+y42Wi/1dysq1WB6w4xMEuyNMVC6b3KUiUMdu7Dehk8DjWWHre4ngsD3IQYYfYyGulMfpBqqBXaKN2l2FA2kALGYVY0XonsnE9vG4ZW7yUmcRpvF1N5IQ+UuMo2p16QpvtAM7Q838+9FOvMS/p0aPaFhSCpVe9MuRw06T3qYtTd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6060326)(6045199)(6040361)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025);SRVR:AM5PR0701MB1873;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB1873; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;4:7GmS8jgnW7I1mbT3ptExIXfkVoUqJmNPfqrkzRm9XXW7ZNvA3rxdEB1tFvZdoYDgQgXuz+LzYe3GAmH4cOOr5wYLj6rruE4ukfvL3VVPERaKQJuevp1tOW85VJUKaghxCPmp+fowufjqFD1cHj+dgcaDwVYh2hD9eracIXKUCLKccqP1guRFi0E9x/J7XUgitEJ0AigfeJ6HpIcSALO3unVCT2x0idDXssGm2Flw8MCiwtZQqvxHxfH1ChqV0vNYe3xzYSE87Od2CPJ75XXbEfXLSjgSwzMoSjSbtST7qpJZIJJ4QwjhJSAaAprB3U1hA9GykP8/dlhsgXCTPyEoatOXhfQF01wIIA8NKwMP98zvyRaY0yk1uMFeEVzAUvvxHO3ZYmPRXcOq/1z7+PCosOzD1VoCFd+/GWqzXJZcGjDk6NB+0AejTF7FrXi8EDUg5AwiuQ6m1jhnRy/zr3ljWVT4WLoYD9WEn2ml8mc6vEUt/yUdlG7OaSyxy2YWIdxRsFdCp6RTRCyoAg1dqgLSuPW1EwktpLZcT4UyyAdoN/JQJ8hq4y02hq7Zg2vFHlq/znp/FDpZfrhW2tSCImE1gQPH/sNwWRTKj/yXUH+OWgU= X-Forefront-PRVS: 01371B902F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(7916002)(52314003)(24454002)(189002)(199003)(43544003)(105586002)(68736007)(81156014)(66066001)(50466002)(47776003)(81166006)(5660300001)(6200100001)(6116002)(48376002)(3846002)(86362001)(189998001)(39400400001)(39410400001)(39380400001)(83506001)(4001350100001)(97736004)(39450400002)(33646002)(8676002)(93886004)(77096005)(54356999)(101416001)(5003940100001)(106356001)(7736002)(305945005)(7846002)(92566002)(76176999)(2950100002)(38730400001)(6862003)(50986999)(39060400001)(110136003)(36756003)(2906002)(4326007)(6666003)(42186005)(229853002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0701MB1873;H:elxa4wqvvz1;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A: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;AM5PR0701MB1873;23:2DwHWOQnC24+Eh8U8xD4Mnamu5727FQiJleNZdH?= =?us-ascii?Q?vjJcpnBszgRZJK5S24fxxBsqIp70ybFHniNF4l4apxKgHbNYkGDL5n+jKuRg?= =?us-ascii?Q?ZpsD+yq0+I/wO1HdGUiK4S758qqoumw1mwC+lELfQ7/MEj2SRih4P8jXfbBB?= =?us-ascii?Q?1/La55h4iy7npB++LNbzJ6UicI18o+hFpsFW49k8ZrNyrxiEOkFSpkx8cIl0?= =?us-ascii?Q?nVL45HLGMVCQkgQarhDLuBW7ROhADXwKPeG72kF1S1Eb7/uWrqRHgd7gBvCb?= =?us-ascii?Q?/udB2AYwvjH42h9/ZdnpKZyj2/LDkW32+WB1BqSclbEc34dMxFYjx94B51iH?= =?us-ascii?Q?LWZ3DVq6ep0yXb8GCvC00qlbUPsDsxdMe/1GHWTmjjZqqBA7my1MVSlL5XVE?= =?us-ascii?Q?oRWnli8rKMaBYhIrpXQu43dbHJQtVSePRjTIsT3zPLemklIOWc1ubze1/OEo?= =?us-ascii?Q?lOkOa6E/opGiBWwXVvl28CARdXerfpuiGtmtJUkyCbp/wkLZVE02F9DHLGUb?= =?us-ascii?Q?IR+EDRrQyKwg4E4pdi2D41VB+QK9As4CF5ZChOsxQIN/qCDbBLkTsDbbAR7f?= =?us-ascii?Q?gBFayuFismlZjh5TUQ24CS2AyUST3jCePosrfXuCXxMVdn7f66PXy7g+f2it?= =?us-ascii?Q?TPQZscO6Nn7Rll3iLg4sjous+fxd1pL0UdbGyItYWsuqkQKAEzeU/T/7wfvR?= =?us-ascii?Q?5Oon/2/VcJj9NDIz4XnSIYRZDxpURiSSurp9LZP3csvZQECAp2rUqTxbWh7G?= =?us-ascii?Q?nHAHQQWzMpKmwtyEcSJSLcVayk0YeCc7I6pP48LxctigP++L/k+N8rXHeEaa?= =?us-ascii?Q?aj5QQYZDxF7pTCxT2a/6d9Lo+om+hbmJWFP0hhf04U5Yi9AF/9iKL48evRAB?= =?us-ascii?Q?dgzQja1QqE4gOl406xpIgnBIBBGMEs3YE1UNLVDIdX+v0FuM93BwfOY1+tv3?= =?us-ascii?Q?7XKhXfYKFqe8irUoBhOLw7tCp4D7MyL1A6t0zY6CmaSUBI1MOMnZ2vM8MCF6?= =?us-ascii?Q?/bbmxe4GoTAO6bXqJFWrF5ALvmlfliFjqplpAtgc9X3SRv1+2yr53H38q8BS?= =?us-ascii?Q?HCaAwzw0rIXadyaMYXOdXqYLzD42BSopddLdkt73aC/WJWgtUbD5NS3bYaJ/?= =?us-ascii?Q?qdYhYaxWTn+1rsfIc9bIsOVRGp4Xn/xA26hZ4y2/nhtI4D2XPm4x5tXsUpBb?= =?us-ascii?Q?/W1jtXHOwqXDq8XfehkisqfHp2AtoT7/lAdR8rkAhNsUJFR6KbDMUXP/qlwT?= =?us-ascii?Q?2INquofdQSvdUlfYuJ3G/J7kHUfzihTUfniVt6qEAIDo4onkWHsrFnIY9N0O?= =?us-ascii?Q?XjRWALdPQH/lavdPAXaD9YMLQExDDZs1vq7+AyvptK/ru?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;6:ChOvaSyJsgeLwOvzqB2HENfBfEseUxZuWR4qYPd1QD9o/zsSB5/oQyL+SDgYRu0pwdkvPuDel6mbj8CP7NeFVoRlFHrIHaPE44WiHdWizpVZYr2aF2IUjIPgupeaWsDZelOjZkWXU1UGTcjrZiDi4vTE9PPrGRHm7A+763EY92os/tWul2ZtGIW1nddDF8CWNX1Anuoe2S8rqxp7pKlL1pSH8XdsXzQkNf5sYg/nGvAHwtYF9PKqOj1e3jlLRwcKbA7VoemZiyiXFL6t3tt8D8FqnZd7b40ZaTxrmVOfARuzY0BnU3nyz9WBBEXcjz7v49Cb8IgOmx8mEW8esbjtLQ+m3sUDF4Rpmow4r2hkrP8pb1il3AK0KJ7bryCnZTIfzpDjfy3ViW7d3R20PmN0dpM5Q0CfZFY4QWXmvMlHjZ6PcNfD/wFdqq0H8xArwUYGaiQSGihBnCAT4jJOuslIpw==;5:NtaytyQvPCFQauawOTQZ8OKLM1bi1+t+n6Q1osF9abSJGpyacsXInWAyWezXMEi5hrx8yTNWmDvAV+W9EwE5Ws5qanyvhOkV2cq+Sr5stUpurp5NPVH/3Hm28bISyHqkbsiIw/jtjwsgAmIV2h5JoCgRDDrtswPiRRKNFLHMn3Q=;24:K2X3joczs9wWpHpBTd1lZCfKLKsSJ1DNrY9hsfztLFX6ZYZBcUqnqb9HQhBleIy98G4N8/HCnJnq9VYEvsSmZGw7kIzPWuiveMy++4k8vZs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB1873;7:U9+L/iBI7W0LTyJrVvvlmkGeDX++LNJI3G6s08O0cz8/c4QXlWnyLp7MLU0j8mUy7RlN6xkkKBXfhbhgWOoo4zCB9MyU02oU8MLNQOwN3JNJF1qnP9GkogR7BZPpKWRXD+xAABn++XtudCWmcc17Bq5S2gNxb58DgYrjeVdIRUgIOdO33/wVbeUCs2AMalVhXmphSw0H7YjqsJ79+M1toHPx8GprgsVPSVhvmzUDVKym3+sm8dGCPvOXOpE0HD+bxdE/DYFQRcRmckA5LrEM7Dthc0oXrIe+oZmhb4ZMkPTPJ3SyXYD4iMbx+YwLEwZrNiKUQId60NLsKYuBpZxWSVjSeX9QhUIlkiTlj+rBk2P1R6E5fEUcpxpDaU5OE614Lw6pZEzhVO7gO+fEaU68plVKI3EQ/sy6JIi7HH/MU0QdJPlP+q+ylZFPvgqH7DX0ngRGPaG/r3YvNLz0dpx6rg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2016 13:34:59.2882 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1873 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00805.txt.bz2 Antoine Tremblay writes: > Antoine Tremblay writes: > >> Yao Qi writes: >> >>> On Mon, Nov 21, 2016 at 10:34:44AM -0500, Antoine Tremblay wrote: >>>> > Thread 1 either sees the original instruction on address A or the >>>> > breakpoint instruction. Unless ptrace read/write 32-bit is not >>>> > atomic, IOW, partial ptrace write result is visible to other >>>> > threads, I don't see why we get SIGILL here. >>>> >>>> I think this is the problem, ptrace read/write doesn't seem to be >>>> atomic, and thread 1 sees some half written memory. (Given that we get >>>> SIGILL/SIGSEGV issues) >>> >>> We need to check in linux-arm-kernel@. >>> >>>> >>>> Did you have any reference suggesting it was atomic ? >>>> >>> >>> No. >>> >>>> While testing it seems to be atomic for 32bit writes but in thumb mode >>>> with a 16 byte write, it is not. >>> >>> I think you meant "16 bit write". Why is that? >>> >> >> Yes 16 bit write sorry, because it can write a thumb breakpoint : >> 0xde01. >> >>>> >>>> Given the SIGILL/SIGSEG I get maybe that one is 2 writes of 1 byte ? >>>> I'll have to dig in the ptrace code I guess. >>>> >>> >>> It is good to get some a clear answer instead of ambiguous speculation. >>> I think we need to ask in linux-arm-kernel@ >> >> Did you see my follow up email ? : >> https://sourceware.org/ml/gdb-patches/2016-11/msg00681.html >> >> Also, I think this will become a moot point in the patch I'm about to >> post since: >> >> To install a single step breakpoint on a thread GDBServer needs to make sure >> that there is not a breakpoint at the thread's current pc, since it >> can't determine what is the next_pc of a breakpoint instruction. >> >> Usually for stepping over it's OK since it's stopped at pc X and it >> will install a single-step breakpoint at pc X + next_pc_offset. >> >> So need_step_over returns true and GDBServer starts a step_over process, >> which removes all breakpoints, installs a single-step breakpoint on the >> nextpc and resumes. >> >> But in this case it is installing single-step breakpoints in threads at >> different pcs then the one we're stopped, so the step-over process is >> not triggered and it should not be. >> >> So GDBSever does not take care to remove all breakpoints like is the >> case in the step-over process. Because of that it can try to install a >> single-step breakpoint where there is already a breakpoint in memory and >> thus break get_next_pc and install a breakpoint at an invalid location. >> >> Consider this case: >> >> in non-stop, thread 1-3 are stepping in a loop similar to >> non-stop-fair-events test. >> >> - thread 1 hits its single-step breakpoint at pc A. >> - delete its single-step breakpoint. >> - a check for need_step_over is done, but there's no breakpoint at pc A >> anymore, and nobody is stopped there anyway so it returns false. >> - proceed_one_lwp is called on each thread. >> >> Now here is the problem: >> >> thread 1 is at pc A >> thread 2 is at pc B >> >> B is a branch to A. >> >> thread 1 installs a single-step breakpoint at pc B since it's range stepping. >> thread 2 does not have a single step breakpoint but needs one installed. >> >> - proceed_one_lwp finds that it needs to install a single-step >> breakpoint on thread 2. >> >> - It calls install_single_step_breakpoints, which calls get_next_pc. >> >> - get_next_pc reads the current instruction in memory at pc B, but >> since it's a breakpoint, it missinterprets the instruction, you can't >> step over a breakpoint like that anyway, but this is what happens >> now. >> >> A single-step breakpoint is now inserted at an invalid location. >> >> So my approch in my patch is to fix this by always removing all >> breakpoints and fast_tracepoints_jumps, like we do in start_step_over >> before calling install_software_single_step. >> >> This makes the breakpoint installation a multiple steps process and thus >> can't be atomic. >> >> WDYT ? >> >> Thanks, >> Antoine > > In fact thinking more about this we may need to remove all breakpoints > at any pc since get_next_pc may read memory in other places then the > current pc to deal with atomic sequences for example or for other > instructions too. > > If it reads a breakpoint in memory there it may come-up with an invalid > next pc. > > This is a problem with the current step-over logic too. > > So we would either need to be able to read past any > breakpoint/fast_tracepoint_jump... anywhere > or uninstall everything before calling get_next_pc. > > I'm not sure which one is best at the moment, opinions on this are > welcome. Sorry for what may seem like a monologue there, but we can't read past breakpoitns etc all the time since we have know idea of the memory aligment involved, we don't want to check around a single byte read to see if it looks like a breakpoint. So before any call to get_next_pc, we need to remove everthing, I'll send a patch in that regard. Thanks, Antoine