From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47926 invoked by alias); 30 Mar 2017 15:55:54 -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 47904 invoked by uid 89); 30 Mar 2017 15:55:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mga06.intel.com Received: from mga06.intel.com (HELO mga06.intel.com) (134.134.136.31) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Mar 2017 15:55:52 +0000 Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 30 Mar 2017 08:55:51 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga005.jf.intel.com with ESMTP; 30 Mar 2017 08:55:50 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.170]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 16:55:49 +0100 From: "Metzger, Markus T" To: Yao Qi CC: "gdb-patches@sourceware.org" , "Wiederhake, Tim" , "xdje42@gmail.com" , "Joel Brobecker" Subject: RE: GDB 8.0 release/branching 2017-03-20 update Date: Thu, 30 Mar 2017 15:55:00 -0000 Message-ID: References: <20170320201629.pbjzaqsnvs7dx7f2@adacore.com> <86zigevkv0.fsf@gmail.com> <86inn1utkp.fsf@gmail.com> <86inmzvrbx.fsf@gmail.com> <86shm2u47t.fsf@gmail.com> <86wpbbnf1f.fsf@gmail.com> <86shlyoggb.fsf@gmail.com> <86mvc5o7o4.fsf@gmail.com> <86a885o0z2.fsf@gmail.com> <861stgo072.fsf@gmail.com> <86lgrn3uos.fsf@gmail.com> <86h92a4w86.fsf@gmail.com> In-Reply-To: <86h92a4w86.fsf@gmail.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00527.txt.bz2 SGVsbG8gWWFvLA0KDQo+ID4gQW50aWNpcGF0aW5nIHN1Y2ggYSBjaGFuZ2Us IEkgd291bGQgZG9jdW1lbnQgY2xhc3MgUmVjb3JkSW5zdHJ1Y3Rpb24gYXMg d2UNCj4gPiBkaXNjdXNzZWQgYnV0IGtlZXAgUmVjb3JkQnRyYWNlSW5zdHJ1 Y3Rpb24uICBXZSBtYXkgaW50cm9kdWNlIHlldCBhbm90aGVyDQo+ID4gYWJz dHJhY3QgYmFzZSBjbGFzcyBSZWNvcmRJbnN0cnVjdGlvbi4gIE9LPw0KPiAN Cj4gV2h5IGRvIHdlIHN0aWxsIGtlZXAgUmVjb3JkQnRyYWNlSW5zdHJ1Y3Rp b24gaW4gUHl0aG9uPw0KPiANCj4gPiBXZSBtYXkgbm90IG5lZWQgdG8gZG9j dW1lbnQgY2xhc3MgUmVjb3JkQnRyYWNlSW5zdHJ1Y3Rpb24gc2luY2UgaXQg ZG9lcyBub3QNCj4gPiByZWFsbHkgYWRkIGFueXRoaW5nIHRvIGNsYXNzIFJl Y29yZEluc3RydWN0aW9uLiAgVGhlIGludGVyZmFjZQ0KPiA+IGNvbnNpc3Rz IG9mIGNsYXNzZXMNCj4gPiBJbnN0cnVjdGlvbiBhbmQgUmVjb3JkSW5zdHJ1 Y3Rpb24uICBPSz8NCj4gDQo+IFRoZXNlIHR3byBwYXJhZ3JhcGhzIGFyZSBz ZWxmLWNvbnRyYWRpY3RvcnkuICBXZSBkb24ndCBuZWVkIHRvIGtlZXANCj4g UmVjb3JkQnRyYWNlSW5zdHJ1Y3Rpb24gaW4gUHl0aG9uLCBqdXN0IHVzZSBS ZWNvcmRJbnN0cnVjdGlvbi4gIFdlJ3ZlDQo+IGFscmVhZHkgYWdyZWVkIHRo YXQgInB1dCBldmVyeXRoaW5nIGludG8gYSBzaW5nbGUgUmVjb3JkSW5zdHJ1 Y3Rpb24NCj4gY2xhc3MgZm9yIGFsbCByZWNvcmQgdGFyZ2V0cyIsIGFzIHlv dSBzYWlkDQo+IGh0dHBzOi8vc291cmNld2FyZS5vcmcvbWwvZ2RiLXBhdGNo ZXMvMjAxNy0wMy9tc2cwMDQyMC5odG1sDQoNClRoaXMgbWF5IGJlIGFuIGlu dGVyZmFjZS9pbXBsZW1lbnRhdGlvbiBjb25mdXNpb24gYWdhaW4uDQoNCkkg dGhvdWdodCB3ZSBuZWVkIGl0IGJlY2F1c2Ugd2UgbWF5IGdldCBSZWNvcmRG dWxsSW5zdHJ1Y3Rpb24gaW4gdGhlIGZ1dHVyZQ0KdGhhdCBuZWVkcyB0byBz dG9yZSBkaWZmZXJlbnQgZGF0YSBhbmQgaW5zdGFsbCBkaWZmZXJlbnQgZnVu Y3Rpb25zLg0KDQpUaGV5IHdpbGwgYmVoYXZlIGlkZW50aWNhbCBidXQgd2ls bCBoYXZlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMuDQoNCkNhbiB0aGV5 IHByZXRlbmQgdG8gYmUgdGhlIHNhbWUgdHlwZSBpbiBQeXRob24/DQoNCg0K PiA+PiA+IFNob3VsZCB3ZSBpbXBsZW1lbnQgYW4gSW5zdHJ1Y3Rpb24gYmFz ZSBjbGFzcyB0aGF0IHRocm93cyBpbiBhbGwgZnVuY3Rpb25zPw0KPiA+PiA+ IFNob3VsZCB3ZSBpbXBsZW1lbnQgYW4gSW5zdHJ1Y3Rpb24gYmFzZSBjbGFz cyB0aGF0IHJldHVybnMgTm9uZSBpbiBhbGwNCj4gPj4gPiBmdW5jdGlvbnM/ DQo+ID4+DQo+ID4+IFRoaXMgaXMgdGhlIEMgaW1wbGVtZW50YXRpb24gZGVj aXNpb24sIG5vdCByZWxhdGVkIHRvIFB5dGhvbiBpbnRlcmZhY2Ugbm9yDQo+ ID4+IGRvY3VtZW50LiAgUHl0aG9uIHNjcmlwdCBjYW4gb25seSBnZXQgUmVj b3JkSW5zdHJ1Y3Rpb24gb2JqZWN0cyB2aWENCj4gPj4gUmVjb3JkLmluc3Ry dWN0aW9uX2hpc3RvcnksIGFuZCBSZWNvcmRJbnN0cnVjdGlvbi57cGMsIGRh dGEsIGRlY29kZSwNCj4gPj4gc2l6ZX0gc2hvdWxkIGJlaGF2ZSBhcyB3ZSBk b2N1bWVudGVkIGZvciBJbnN0cnVjdGlvbi4gIFNvIGZhciwgdGhhdCBpcw0K PiA+PiBubyB3YXkgaW4gcHl0aG9uIHNjcmlwdCB0byBnZXQgSW5zdHJ1Y3Rp b24gb2JqZWN0cy4gIFdlIGNhbiBlaXRoZXIgdGhyb3cNCj4gPj4gZXhjZXB0 aW9ucyBvciByZXR1cm4gTm9uZS4gKEkgcGVyc29uYWxseSBwcmVmZXIgZXhj ZXB0aW9ucywgaWYgeW91DQo+ID4+IHJlYWxseSB3YW50IG1lIHRvIGNob29z ZSBvbmUpLg0KPiA+Pg0KPiA+PiBTdXBwb3NlLCBvbmUgZGF5LCB3ZSBhZGQg YSBuZXcgcHl0aG9uIGludGVyZmFjZSBsaWtlDQo+ID4+IGdkYi5JbmZlcmlv ci5yZWFkX2luc24gKHN0YXJ0X3BjLCkgcmV0dXJucyBJbnN0cnVjdGlvbiBv YmplY3RzLiAgVGhlIFRoZXNlDQo+ID4+IG9iamVjdHMgc2hvdWxkIGJlaGF2 ZSBhcyB3ZSBhbHJlYWR5IGRvY3VtZW50ZWQuICBJbiBDIGNvZGUsIHdlIGNh bg0KPiA+PiBjaGFuZ2UgSW5zdHJ1Y3Rpb24ncyBnZXRzZXQgZnVuY3Rpb25z IHRvIGRvIHNvbWV0aGluZyBtZWFuaW5nZnVsIHJhdGhlcg0KPiA+PiB0aGFu IHRocm93aW5nIGV4Y2VwdGlvbi4NCj4gPg0KPiA+IFdlIHdpbGwgbmVlZCB0 byBpbnRyb2R1Y2UgYW5vdGhlciBkZXJpdmVkIGNsYXNzIERpc2Fzc2VtYmxl SW5zdHJ1Y3Rpb24NCj4gPiBzaW5jZSBpdCB3aWxsIHdhbnQgdG8gc3RvcmUg ZGF0YSBpbiB0aGUgcHl0aG9uIG9iamVjdCBhbmQgd2UgZG9uJ3Qgd2FudCB0 aGF0DQo+ID4gZGF0YSBpbiBSZWNvcmRJbnN0cnVjdGlvbiBvYmplY3RzLCBz byB3ZSBjYW4ndCBhZGQgaXQgdG8gdGhlIEluc3RydWN0aW9uIGJhc2UNCj4g PiBjbGFzcy4NCj4gPg0KPiA+IFRoYXQncyBhZ2FpbiB0YWxraW5nIGFib3V0 IHRoZSBpbXBsZW1lbnRhdGlvbi4gIElmIHdlIGNhbiBtb2RlbCB0aGlzIGlu DQo+IA0KPiBXaGF0IGlzICJ0aGlzIj8NCj4gDQo+ID4gUHl0aG9uIHdpdGhv dXQgaW50cm9kdWNpbmcgbmV3IGNsYXNzZXMsIEknbSBmaW5lLCBhcyB3ZWxs LiAgV2Ugc2hvdWxkDQo+ID4gYWxzbw0KPiANCj4gIndpdGhvdXQgaW50cm9k dWNpbmcgbmV3IGNsYXNzZXMiIGluIEM/ICBXaGF0IGFyZSB0aGUgIm5ldyBj bGFzc2VzIiwNCj4gRGlzYXNzZW1ibGVpbnN0cnVjdGlvbj8NCj4gDQo+ID4g ZG8gaXQgbGlrZSB0aGlzIGZvciBjbGFzc2VzIFJlY29yZEluc3RydWN0aW9u IGFuZCBSZWNvcmRCdHJhY2VJbnN0cnVjdGlvbiBpbg0KPiA+IHRoYXQgY2Fz ZS4NCg0KVGhpcyBpcyB0aGUgc2FtZSBhcyB0aGUgYWJvdmUuIA0KDQpSZWdh cmRzLA0KTWFya3VzLg0KDQpJbnRlbCBEZXV0c2NobGFuZCBHbWJIClJlZ2lz dGVyZWQgQWRkcmVzczogQW0gQ2FtcGVvbiAxMC0xMiwgODU1NzkgTmV1Ymli ZXJnLCBHZXJtYW55ClRlbDogKzQ5IDg5IDk5IDg4NTMtMCwgd3d3LmludGVs LmRlCk1hbmFnaW5nIERpcmVjdG9yczogQ2hyaXN0aW4gRWlzZW5zY2htaWQs IENocmlzdGlhbiBMYW1wcmVjaHRlcgpDaGFpcnBlcnNvbiBvZiB0aGUgU3Vw ZXJ2aXNvcnkgQm9hcmQ6IE5pY29sZSBMYXUKUmVnaXN0ZXJlZCBPZmZpY2U6 IE11bmljaApDb21tZXJjaWFsIFJlZ2lzdGVyOiBBbXRzZ2VyaWNodCBNdWVu Y2hlbiBIUkIgMTg2OTI4Cg== >From gdb-patches-return-137884-listarch-gdb-patches=sources.redhat.com@sourceware.org Thu Mar 30 16:06:15 2017 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 115097 invoked by alias); 30 Mar 2017 16:06:14 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 110803 invoked by uid 89); 30 Mar 2017 16:06:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f194.google.com Received: from mail-wr0-f194.google.com (HELO mail-wr0-f194.google.com) (209.85.128.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Mar 2017 16:06:11 +0000 Received: by mail-wr0-f194.google.com with SMTP id k6so12116522wre.3 for ; Thu, 30 Mar 2017 09:06:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=DWddiJzI6VonUeS3VM6PHOD3hR6EstW1aCWO4RwgEAc=; b=Eg9PILc/g2kq3rHyZaOaIjd2UUvow6v6SBj9Ls8fkAxDHFT+y9OG2uBCdR3S4Z7Lgd vPQ0vjpLahz9geqtZm3RNwTilNma0W64WL1k4x3IVJB6FwiSsTVajnq3oavODsYInJEo kWixyKykULqa3sU0EUHX5xx7DrHyTNMBHDEHNXS21njMmJRVludtTfao9VN3vjO37FNI rnLlR2zJSMHqFS6DG9wCPyXZ+9jvZwmGzWGXaqa+/JHS4ExTKClgQAxiFyRIXIt2iB+6 W0LDd648ZAnYfNx6HQj/hQ4drD7Anqa2i8glsQbsvNGY1rGFFIpOImww1u+wBHx0geko a+AA== X-Gm-Message-State: AFeK/H2CgDcxCAtpldioF/bJuwFtUhwGHtWQw+qWq6gvoM1bDo7HniADFxm/rC8CCc9trA== X-Received: by 10.28.71.87 with SMTP id u84mr4337608wma.101.1490889970272; Thu, 30 Mar 2017 09:06:10 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id 127sm3755926wmt.20.2017.03.30.09.06.08 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 30 Mar 2017 09:06:09 -0700 (PDT) From: Yao Qi To: Antoine Tremblay Cc: Pedro Alves , "gdb-patches\@sourceware.org" Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> <2255ed6f-a146-026c-f871-00e9a33dfcf0@redhat.com> Date: Thu, 30 Mar 2017 16:06:00 -0000 In-Reply-To: (Antoine Tremblay's message of "Wed, 29 Mar 2017 08:40:22 -0400") Message-ID: <86d1cy4umo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00528.txt.bz2 Content-length: 5500 Antoine Tremblay writes: >> In software single step, we calculate the next pcs, and select >> breakpoint kinds of them, according to current pc. If current >> pc is not within IT block (!InITBlock ()) or the last instruction >> in IT block (LastInITBlock ()), we can safely use 16-bit thumb >> breakpoint for any thumb instruction. That is, in >> gdbserver/linux-aarch32-low.c:arm_breakpoint_kind_from_current_state, >> we can return ARM_BP_KIND_THUMB if (!InITBlock () || LastInITBlock ()). > > This is not entirely true since we have to check if the next pcs are in > an IT block rather then only the current one, so there's multiple > scenarios. In fact, we need to know whether the next pcs will be conditionally executed or not, right? If they won't be conditionally executed, we can use 16-bit thumb breakpoint instruction. By checking CPSR, if current PC is not in IT block or on the last instruction in IT block, the next pcs can't be conditionally executed. I've already had a patch below to implement what I described. 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. > > Consider if current PC is the IT instruction for example, then there's > at least 2 next pcs inside the IT block where we will need to install an = THUMB2 > breakpoint and get_next_pcs will return that. --=20 Yao (=E9=BD=90=E5=B0=A7) =46rom fad6162c9365535a09ca1072f15469e6007c0fd2 Mon Sep 17 00:00:00 2001 From: Yao Qi Date: Fri, 24 Feb 2017 09:25:43 +0000 Subject: [PATCH] Only use 32-bit thumb-2 breakpoint instruction on necessary It takes two PTRACE_POKETEXT calls to write 32-bit thumb-2 breakpoint to a 2-byte aligned address, and other threads can observe the partially modified instruction in the memory between these two calls. This causes problems on single stepping multi-thread program in GDBserver. 32-bit thumb-2 breakpoint was invented for single step 32-bit thumb-2 instruction in IT block, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/007488.h= tml but we can use 16-bit thumb breakpoint instruction anywhere else. That is what this patch does. Change in set_breakpoint_type_at is similar to breakpoint.c:breakpoint_kind. This patch fixes fails in gdb.threads/schedlock.exp. Even with patch, 32-bit thumb-2 breakpoint is still used for 32-bit thumb-2 instructions in IT block, so the problem is still there. This patch is a partial fix to PR 21169. gdb/gdbserver: 2017-02-24 Yao Qi PR server/21169 * linux-aarch32-low.c (arm_breakpoint_kind_from_current_state): Set kind to ARM_BP_KIND_THUMB if program is out of IT block or on the last instruction of IT block. * mem-break.c (set_breakpoint_type_at): Call target_breakpoint_kind_from_current_state to get breakpoint kind for single_step breakpoint. diff --git a/gdb/gdbserver/linux-aarch32-low.c b/gdb/gdbserver/linux-aarch3= 2-low.c index 2b710ba..7409050 100644 --- a/gdb/gdbserver/linux-aarch32-low.c +++ b/gdb/gdbserver/linux-aarch32-low.c @@ -288,7 +288,30 @@ arm_breakpoint_kind_from_current_state (CORE_ADDR *pcp= tr) if (arm_is_thumb_mode ()) { *pcptr =3D MAKE_THUMB_ADDR (*pcptr); - return arm_breakpoint_kind_from_pc (pcptr); + int kind =3D arm_breakpoint_kind_from_pc (pcptr); + + if (kind =3D=3D ARM_BP_KIND_THUMB2) + { + unsigned long cpsr; + struct regcache *regcache + =3D get_thread_regcache (current_thread, 1); + + collect_register_by_name (regcache, "cpsr", &cpsr); + /* Only use 32-bit thumb-2 breakpoint if *PCPTR is within + IT block, because it takes two PTRACE_POKETEXT calls to + write 32-bit thumb-2 breakpoint to a 2-byte aligned + address, and other threads can observe the partially + modified instruction in the memory between two + PTRACE_POKETEXT calls. + + Don't use 32-bit thumb-2 breakpoint if program is not + in IT block or on the last instruction of IT block, + (ITSTATE.IT<2:0> =3D=3D 000). These bits are from CPSR bit + 10, 25, and 26. */ + if ((cpsr & 0x06000400) =3D=3D 0) + kind =3D ARM_BP_KIND_THUMB; + } + return kind; } else { diff --git a/gdb/gdbserver/mem-break.c b/gdb/gdbserver/mem-break.c index 6e6926a..f3845cf 100644 --- a/gdb/gdbserver/mem-break.c +++ b/gdb/gdbserver/mem-break.c @@ -855,7 +855,21 @@ set_breakpoint_type_at (enum bkpt_type type, CORE_ADDR= where, { int err_ignored; CORE_ADDR placed_address =3D where; - int breakpoint_kind =3D target_breakpoint_kind_from_pc (&placed_address); + int breakpoint_kind; + + /* Get the kind of breakpoint to PLACED_ADDRESS except single-step + breakpoint. Get the kind of single-step breakpoint according to + the current register state. */ + if (type =3D=3D single_step_breakpoint) + { + breakpoint_kind + =3D target_breakpoint_kind_from_current_state (&placed_address); + } + else + { + breakpoint_kind + =3D target_breakpoint_kind_from_pc (&placed_address); + } =20 return set_breakpoint (type, raw_bkpt_type_sw, placed_address, breakpoint_kind, handler,