From patchwork Fri Mar 31 18:22:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Antoine Tremblay X-Patchwork-Id: 19786 Received: (qmail 2439 invoked by alias); 31 Mar 2017 18:22:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 2413 invoked by uid 89); 31 Mar 2017 18:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=alarm 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, 31 Mar 2017 18:22:30 +0000 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id C9.8C.26215.36E9ED85; Fri, 31 Mar 2017 20:22:29 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 31 Mar 2017 20:22:26 +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 VI1PR0701MB1887.eurprd07.prod.outlook.com (10.167.197.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 18:22:22 +0000 References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> <2255ed6f-a146-026c-f871-00e9a33dfcf0@redhat.com> <86d1cy4umo.fsf@gmail.com> <86d1cxwgpk.fsf@gmail.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Antoine Tremblay To: Yao Qi CC: Antoine Tremblay , Pedro Alves , "gdb-patches@sourceware.org" Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping In-Reply-To: <86d1cxwgpk.fsf@gmail.com> Date: Fri, 31 Mar 2017 14:22:10 -0400 Message-ID: MIME-Version: 1.0 X-ClientProxiedBy: MWHPR13CA0013.namprd13.prod.outlook.com (10.169.208.23) To VI1PR0701MB1887.eurprd07.prod.outlook.com (10.167.197.23) X-MS-Office365-Filtering-Correlation-Id: 372ec312-27f8-4e40-db11-08d47862e10d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR0701MB1887; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB1887; 3:4d0+8nVHNTsGDgSBtGqIbf5knsKQt7MEYnUnOtroWG/oC5WcXS/FY60kfSQoXMENefNGcVJQIGm9SP1J5UeXoxytm51Q1tveaaz1L4Wneiy5McfJ243K1M9eWDX8PnREIh793RFpQ7TGOWmXWsXjYXGoXoJJJc0/6zyULykaviXClNzIPG5dKWfhj18asIRmmuqnlUVwlkb++bWn6qWc41CqjColSXlfWFXTUD3lU3FzfNbPvcjXkxMJYgoRzSk15gIDhSBXq+a6cyc2GoGhR5sC0fPxXKoNgPLInblqcuJaCjQqhhFSfuDrlqd7uE/Pz5R5qKHxGkMZ/yOYCdJX+Q==; 25:lqBBTA5iPqUqgrdkgOfttFVlxOphOIDxLbGKj+X3z9XoA2AfnOx9WzuFmQZjsnsBE2EqgANEEgWJ9ka08VdltXSXUnebzFWtCHxPcGPOsRTvX6ApcP30nyYMyuJfnoiOVVLhvKn3v25ogWnKbQ1ll3Yyri07hjg6a/pvkHeLJF+v48hE0+g2gQkFimcy/7ep2ZSLOZ8nDWFVwk4pq/QU1HRjXLrjIC9ipHQFJWJotWxZZEdSA8kKUVlsRR/XVhN+wlBVa+D8Y40AEoEqIHvAgaYqe+niwXYtpr8LPvi/R2kRah0znCXt3NiPJOoHFB+2WEcenuMhb9gkQRpXkSFUSqAltE2PkbnHQTl6ODcRq10Z/wYG02Mzgq/fWllKW0UrgjqA9mu/2Cp5zLy5nEavDgtlcQVT9M5w0sTSAtvbk2sByrO69v7E7HJ/+oY21so7+K2SjQQ9Z62VMLOmhYIMoA== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB1887; 31:gFeL2mR8k9v19EEcT5qQ+9TDN1jCHh9E4FIzmVLUDTK5XJh4bTQLiu102dmwbGJPztudDe8Y5SpzNSn3xe79BPgG2NZl3K02V2g31o4vYk5g6j8VJ3gHSZAV2mA5M/fQ9jZqHVQ/9YQnMIR5hl76aGz8k77CCMrNZC6/CxeXJ5C7cSU4jpW1OCpTJ4knKhnJM/dQLhAewoOlO8XMymNGg0h61xrSgn/ZwLcW2aIxZwo=; 20:Y7FXKTh+Ueto5LS7XnQevDblHwjy52ODJhnz+aJK+RKkzmYSOaNKoHuife+ERdi5z5wTEagA6B31BZgjBWCHwB38S9/T73a/eZOrS21GqYFd0uJHbiDqsqNozLLe2K7V8gZGdNk26/aB03yewslDxOZlz12ycqFdgL8D4s7Hn+bQYAkCGNsUgaG2MgPonzWiZbqvGzxZ4qOl/G9M1QPQu6uH5nUVL/acBX3KCjrfKDwBeTLx7ZjaXtEK7ClTcDvxFo28vaMZhnur8eU8DBPAYsTyDSAl5l3/SoHm7b2w0b/PQ1C8r5C7WJ/Aq0zCOs01s8AepY7cs2nCwMZ9alNOo3K7sbTdBFCuGBtoJnLmOp4uO6eCuhz89MXeMN5c3/PfG3T+a/+aZdgGYdZIwAZQKntRJM2RSYiv2RPmebDvTMw6Xkm5luAmKjIl3OEhUCWbNb5kpPBUbr6QlRAFdlFc8m5NsMYWYaCxU+VPyMzKzyrL8qEx+UKAKNhYE4hAiFA4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(250305191791016)(22074186197030); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:VI1PR0701MB1887; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1887; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB1887; 4:hlzupfR251hR0AWndQOSRM8cYjhD98zGQOzzmfqtQm+pz7Gg6yqz9/DIimwXcdXDNy0AeyX3a7bUzrm8DQi54CGUkYkMpanR2loat3sGyieyyIOEnu7phCpSnNPW4VcxAApc5DaxmjFuwjrb1TNBETkCUQqmrKAc2sW42DwL68A5/n2eeLmjoPZu5KPGZKFhf52s92kt2kEQQp9Y5SGWkds5Xib9MU9td+9RddRq9FYNXYUHxLbvOBowkMNkNqkTNdPiARcsiQUJQYYOk4rf0mQxLwymuiLlSOsugufUmFK76CXpfvBCKCVKfbF+eJkIQmuLnddh1mub2k9ni5FWtS5b2ACGxqSKzK6RiAqMrFMKDUj/WwHse0czt0Mgx0mQTJnnQ2I+w+SXY422U3dvpfqhW44eGjBOuTiRS5TqYzks6hofB5W+z0vFpImuYJo8HqR+vGdLCKH8cSzVj7ll7yF02BIu198XCJiGrWitGMorBOSZ83dwUgX5/8EDQqxKNq0ZMw3jToIVZt5SPkivcqnlsqz6wHnZHEuTWO49+2b1rI2UOgVE338VRgmx1xHnlkewrXMol2EZVFQDYvvEIbd4AZx1DipYSuXFgbRRDQri5Usjx8lZrGCnI6zrL7bLrqzpnHR87lTqwlu3tnAKy67AGeb3T04VkRuzA+IaeRC5lTgnAsm5maf4ETlA1BD9Cv0uLjdusEgZ6IeEFiv5aAaps6lO7hTA7ggkL14w6jgj3RkfW4ybgKFzVPMclo25SJ4UzvD4IHy4xc6oksw0V8xb7AGOmuUafO9bjXH1y6Xdw3gzuwM5oO3AHxJx2Ae9FYZLBzcyl2UgMvxO1mOarA== X-Forefront-PRVS: 02638D901B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39450400003)(39850400002)(39410400002)(39860400002)(39400400002)(39840400002)(81166006)(5003940100001)(53936002)(5660300001)(6496005)(33646002)(6666003)(6246003)(83506001)(50986999)(54356999)(229853002)(6916009)(76176999)(2906002)(86362001)(3846002)(2950100002)(4001350100001)(6116002)(305945005)(189998001)(50466002)(48376002)(8676002)(38730400002)(110136004)(4326008)(36756003)(42186005)(6306002)(47776003)(54906002)(93886004)(25786009)(6486002)(66066001)(2004002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB1887; H:elxa4wqvvz1; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0701MB1887; 23:eLpTNgY5Ey3IDla1W+SjoQ3zboVSjCRfmUa9YhO?= =?us-ascii?Q?FHOrCjn6sKHgaUTCQIkAgVlXd0/EHdRodWFT4qooLP+p69UgeOR82gZ0nTuD?= =?us-ascii?Q?tnDcIEiOXcI29IdSREFaIPTHpvDLwdge1VJwn731zj1cS41F+lyUuve9k2X/?= =?us-ascii?Q?AvVSULf9FsgeaO6/L/mGn8wOY6LF/092PSBWyVe9ihin4r9UI07bkh+3bDyS?= =?us-ascii?Q?y/ttflSxS6aSe5d6qoEmhTJDfv750MSFZuAkE2AjttlWLfklgXmc+2cIC9V2?= =?us-ascii?Q?Aolyqc+NBw4Fhys4Oq5yNPMBr6QlAQuw1owFmUItmsdllsBbx26Kn2PpA57W?= =?us-ascii?Q?wdEnSgfM22qIrGo6EGK5xU8gVEEj15VR9GA+AmaRJTSepLrMQ34zxrNHflyO?= =?us-ascii?Q?JouV7rBbzU0wjHryJnHuUR79Kq4u5swxfiBh9Qk/5NmPGe4ph1hVmqOS8oJL?= =?us-ascii?Q?SBaJkXphHozdiFB4VnGtd0oX7EWQRTAKlTjVGGbOKVhf6chEh3cBBNpKSl+Y?= =?us-ascii?Q?d5sCbMgWOwbimB2776x0C4RdJdOwqE35ATgTxqURizxTzS6CU8lU/Ikd3TCv?= =?us-ascii?Q?htxl1kJzEjchSU1cmhi7omf0kF7rmh5poQsrUZrDw+6Zqq0uayA+MbJVz1y9?= =?us-ascii?Q?Yf1ISkxWkO6RJvLnm365yRAvv9Hlws7aLgdRUNl7rKMP0Ru9KZpvn6kKm0Tb?= =?us-ascii?Q?UZvSuQPSTfHXXm7D5s9t2G/qwB4OitKkLZ7BYYDm7Tw5354ZCxGESMf7nza2?= =?us-ascii?Q?ulpYFBpfHVRjwSkUNZR9XW9ll1qJ7GpljjSkcKR2W4JGF2ZViItgtg5wmvKg?= =?us-ascii?Q?QhWXL9UNJ5/DVl+sOMSyn2m9HLtr28zrMeM0dZRAyOQh5OwItH5R3x7FSLWL?= =?us-ascii?Q?fNnYQiYCRljqQEOO6r4VpK8zszXLZIFVuOxUL9Z4eFqgVnKiy34AI6egazS+?= =?us-ascii?Q?zyhdAdujiLZ7c2uSKk97YqLWP4sx5uenghTzvbITTUPMEs8BV2S9moRdxIlJ?= =?us-ascii?Q?EtXElnqXlDQ/FNHSHUTxduA2+uAbeQrjaRnAGsOpZjjy7A3ZqOz/hkcWwn3s?= =?us-ascii?Q?SFIkjzw8ELl6lk2qeSgkfpeaL3xWQChUChRRC3TUqKFYkUfzuLcwShLhDkT1?= =?us-ascii?Q?WXsIbPHRxyzJZV/hTZzvJkjgkxLCwrNiX2nVKvlXyxJb/t8PiDLtoVA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB1887; 6:v+eySP3C4u2nhvwJIBzZyruSvpD+Y0o1Kd7coNM5e8lwZ+FbG7Dg2CFl4v9GuWokaCwhILgNWKBgjrtecdl1DQEtbA4jRR36NKyeSjPjs9FQZnAi97WH/kXP1G+ROqZQ8BJ83O0rnPa3DDmy4H6Y/s93EhCgKB3D0NR4zMCzYM7aFdbUFcZI6jbPkiyhZBETiL+YeEFfuBUCeDAMXKMvrZDQS9SazAx1EvaGIHwTTJxi832p1vyGO+lcnK5G+rOWqExJPEXETJLNYy8AIdHUej1Qc2jFVZ2856l0fJgpST6l7Sz7OGNP9K5Q9ukc9IKmk32ne+eOFfOJoaZL3/f0q4rub428j4Hu7RwNEqAdqludqzgcRiIfx8bdPs+R6wcj2tPAe8CoqkArOjkZTowdFg==; 5:23w9CVWJPYgWJ10r0ZufJJNMiCTtAq+Vh2fHmijRPB0u4+szh9urrAP+t9nujzZnLG1/MxFyyyRdV6LdO/NqE96TJlKRNhNbKTRo1ROAA79lp8xx6ipdjeoBr8g4MiEG84nCrtaGEscmSvQ8Sq6ACA==; 24:R4hsszwDwbQfkzO2rA+csmp+2rW81OJJXOpLxWZpBnGd8g4qS+VTFAcMvdpXWpltr2jyGuxKfj4CxWEf/VgvWXC4qR7COtoPiZAzhc/x3j4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB1887; 7:2IKZJqHU4lQRoeyavwwCyOxNO8H8e4g4PhT3SAA06JNDgTTE1yWWfU4Q4g3LhXEdOcvEoi1u2dIjEiG6aQck6qJNi8FcNpI4cz0DF8ZEmD1GR84TVQLAu5zpI+uQvRXY9hWIL8qHKOSHyuvTKspHity414O/hl1jja5sUwScgZ9KjFb8stfe2gIEinzyRQiNQpn1jO05TKuBoEFFB6sWk5IGtciy5fugbx1TPyKK+N6nBwjMVSdWoJEGnBxgGtD+CoaSBMBnFgp+kAYmhnlH2MqonAuNNKc0gjcp3x87S2SCwFAUd+/jaFDxaEhodrHuUaGhLcFmpEQMbfsDwLOhew== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2017 18:22:22.9310 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1887 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes Yao Qi writes: > Antoine Tremblay writes: > >> You have to add if the current instruction is an IT instruction in wich >> case the next instruction will be in an IT block. >> > > Oh, you are right. > >> Also if you have a conditional instruction that would evalutate to >> true and is not the last one, get_next_pcs may return an instruction >> after the IT block, arm_breakpoint_kind_from_current_state will be >> called from the IT block with that PC and return a THUMB2_KIND when it >> should not. See the else case in arm-get-next-pcs.c:~351 > > With the current PC and CPSR, it is not difficult to know whether > next_pc is still within IT block nor not, because all instructions in IT > block should be sequentially executed or skipped. > I don't think you could figure out that this last instruction that get_next_pc is returning after the IT block is or not in it however without redoing much of the work. I think maybe the best solution would be to abstract only that part of get_next_pc in a function: the if block starting with if (self->has_thumb2_breakpoint) around line 301. And have only that part return the next_pc + the breakpoint kind, this would avoid breaking all the virtual get_next_pc functions just for that case and allow the same code to be used in kind_from_current_state. We'll still redo the work but at least the code will be in one place. WDYT ? >> >> My point was that we should use get_next_pc directly since it's the best >> place to detect if the next_pc is in the IT block. And the intent would >> be clear. > > Yeah, we can record the information of breakpoint type in the return > value of get_next_pc, ... > >> >> It would give something like the patch below. (Note the GDB part of this >> is missing but it works with GDBServer) >> > > ... but using extra bit in CORE_ADDR is not a good idea to me. > Yes it was quite hackish I was able to test with the CORE_ADDR patch that it somewhat works at least. Note that I say somewhat because stopping all the threads is proving more problematic then I thought, I took the inspiration from your original patch series V2 and installed all the single step breakpoints in linux_resume and proceed_all_lwp. But in linux_wait_event_filtered, linux_resume_one is also called with the possibility of a stepping thread in 2 places. And you can't call stop_all_lwps there... So I'm scratching my head on how to stop the threads there thinking about like calling sigprocmask (SIG_SETMASK, &prev_mask, NULL); in there to allow linux_wait_event_filtered to be called recursively... possibly, I just don't see a clean way. There's other issues too where I get GDB adjusting a breakpoint and the inferior crashing.... Might be other issues too :( >>> The problem of this patch is that we end up inserting different >>> kinds of breakpoints on the same instruction. For a given 32-bit thumb >>> instruction, GDB and GDBserver knows 32-bit thumb breakpoint instruction >>> is used for GDB breakpoint, but only GDBserver knows 16-bit thumb >>> breakpoint is used for GDBserver single-step breakpoint, so GDB will be >>> confused on this. I stopped here, and start to do something else. >> >> Humm but how will the GDBServer 16-bit breakpoint be reported to GDB ? >> Won't it always be hit and handled by GDBServer ? >> >> And if you have a GDB breakpoint on an instruction and GDBServer puts >> a single step breakpoint on that GDB breakpoint instruction, GDBServer >> still knows of the GDB and GDBServer breakpoint types. >> >> So how does GDB get confused ? > > That was my conclusion at that point. I got some regressions in > gdb.threads/*.exp when I tested my patch (gdb running is on > x86_64-linux), but I can't remember more details. > OK. Do you remember if it had to do with displaced stepping on ? There's a problem with that and the current code in all-stop. I had fixed that with the original patch from this thread by not removing all single step breakpoints in all-stop... > I am also wondering that we can use some code in > arm_adjust_breakpoint_address about detecting BPADDR is within IT block > or not by scanning instructions backward, if none of two bytes (can be > 16-bit thumb instruction or the 2nd half of 32-bit thumb instruction) > matches IT instruction, the PC is not within IT block. Looking at the code, I think reusing parts of get_next_pc would be simpler. Note I'm including the test I use in case it's useful to you. --- commit ad0288b35d85e96b6c676c665b0063b74a293dab Author: Antoine Tremblay Date: Thu Mar 30 11:14:17 2017 -0400 test single step diff --git a/gdb/testsuite/gdb.arch/arm-single-step.c b/gdb/testsuite/gdb.arch/arm-single-step.c new file mode 100644 index 0000000..e18f4ed --- /dev/null +++ b/gdb/testsuite/gdb.arch/arm-single-step.c @@ -0,0 +1,110 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2017 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +#include +#include +#include +#include + +#define NUM_THREADS 2 +#define TIMEOUT 5 + +const int num_threads = NUM_THREADS; +pthread_t child_thread[NUM_THREADS]; +volatile pthread_t signal_thread; +volatile int run = 1; + +void +handler (int signo) +{ + run = 0; +} + +/* Align the instruction on a 2 byte boundary + Missalign it with a 4 byte boundary. */ +#define THUMB2_INST \ + asm (" .align 4 \n" \ + " nop\n" \ + " nop.w\n" \ + ) \ + +#define ITBLOCK \ + asm (" .align 4 \n" \ + " nop\n" \ + " cmp r0, #0\n" \ + " ite eq\n" \ + " nop.w \n" \ + " nop.w \n" \ + ) \ + +#define LOOP(macro) \ + while (run) \ + { \ + macro; \ + } \ + +void out_of_loop () +{ + return; +} + +void * +thumb2_function (void *arg) +{ + LOOP (THUMB2_INST); /* break thumb2 */ + out_of_loop (); + pthread_exit (NULL); +} + +void * +itblock_function (void *arg) +{ + LOOP (ITBLOCK); /* break itblock */ + out_of_loop (); + pthread_exit (NULL); +} + +int +main (void) +{ + int res; + int i, j; + void *(*functions[2]) (void *); + + functions[0] = thumb2_function; + functions[1] = itblock_function; + + signal (SIGALRM, handler); + + for (i = 0; i < 2; i++) + { + alarm (TIMEOUT); + + for (j = 0; j < NUM_THREADS; j++) + { + res = pthread_create (&child_thread[j], NULL, functions[i], NULL); + } + + for (j = 0; j < NUM_THREADS; j++) + { + res = pthread_join (child_thread[j], NULL); + } + + run = 1; + } + exit(EXIT_SUCCESS); +} diff --git a/gdb/testsuite/gdb.arch/arm-single-step.exp b/gdb/testsuite/gdb.arch/arm-single-step.exp new file mode 100644 index 0000000..c85f981 --- /dev/null +++ b/gdb/testsuite/gdb.arch/arm-single-step.exp @@ -0,0 +1,42 @@ +# Copyright 2017 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +standard_testfile +set executable ${testfile} + +if { [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { + untested "failed to compile" + return -1 +} + +clean_restart $executable + +if ![runto_main] { + return -1 +} + +gdb_test_no_output "set scheduler-locking off" + + +# Test each instruction type, thumb2 is a plain 2 byte aligned but not 4 +# byte aligned thumb2 instruction. itblock is the same but in an itblock. +foreach_with_prefix inst { "thumb2" "itblock" } { + gdb_breakpoint [gdb_get_line_number "break $inst"] + gdb_continue_to_breakpoint "break thumb2" ".* break $inst .*" + delete_breakpoints +# gdb_breakpoint "out_of_loop" + gdb_test "step" ".*out_of_loop.*" "stepping $inst" + # delete_breakpoints +}