From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11569 invoked by alias); 12 Sep 2014 09:53:34 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11560 invoked by uid 89); 12 Sep 2014 09:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Sep 2014 09:53:32 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 826B13B4AC73A; Fri, 12 Sep 2014 10:53:27 +0100 (IST) Received: from KLMAIL02.kl.imgtec.org (10.40.60.222) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Sep 2014 10:53:29 +0100 Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by klmail02.kl.imgtec.org (10.40.60.222) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Sep 2014 10:53:28 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 10:53:28 +0100 From: Matthew Fortune To: Joel Sherrill , Andrew Pinski , Joel Brobecker CC: "gdb@sourceware.org" Subject: RE: GDB dropping support for mips-irix and alpha-tru64 Date: Fri, 12 Sep 2014 09:53:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235320F0A688@LEMAIL01.le.imgtec.org> References: <20140911185249.GA13931@adacore.com> <20140912003052.GB4962@adacore.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00046.txt.bz2 RldJVyBqdXN0IGxhc3Qgd2VlayBJIGNvbW1lbnRlZCBpbiBhIGJpbnV0aWxz IHBhdGNoIGFib3V0IHdhbnRpbmcgdG8NCmdldCByaWQgb2YgdGhlIGlyaXgg Y29uZmlndXJhdGlvbnMgdGhlcmUuIEdpdmVuIGl0IGlzIGNsb3NlIHRvIGEg YmludXRpbHMNCnJlbGVhc2UgSSBndWVzcyB3ZSBjYW4gYnJpbmcgdGhlIHRv cGljIHVwIGZvcm1hbGx5IG9uIGJpbnV0aWxzIGFmdGVyIDIuMjUuDQoNCk1h dHRoZXcNCg0KSm9lbCBTaGVycmlsbCA8am9lbC5zaGVycmlsbEBvYXJjb3Jw LmNvbT4gd3JpdGVzOg0KPiBUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25z ZXMuIFNvdW5kcyBsaWtlIHRoZSBmaW5hbCBjcnVmdCB0byByZW1vdmUuDQo+ IA0KPiAtLWpvZWwNCj4gDQo+IE9uIFNlcHRlbWJlciAxMSwgMjAxNCA4OjMy OjU0IFBNIEVEVCwgQW5kcmV3IFBpbnNraSA8cGluc2tpYUBnbWFpbC5jb20+ DQo+IHdyb3RlOg0KPiA+T24gVGh1LCBTZXAgMTEsIDIwMTQgYXQgNTozMCBQ TSwgSm9lbCBCcm9iZWNrZXIgPGJyb2JlY2tlckBhZGFjb3JlLmNvbT4NCj4g Pndyb3RlOg0KPiA+Pj4gRmlyc3QgSSBhbSBub3QgY29tcGxhaW5pbmcgYnV0 IGp1c3QgaGF2ZSBhIGNvdXBsZSBvZiBjbGFyaWZ5aW5nDQo+ID5xdWVzdGlv bnMuDQo+ID4+Pg0KPiA+Pj4gKyBkb2VzIHRoaXMgaW5jbHVkZSBiaW51dGls cyBhbmQvb3IgR0NDPw0KPiA+Pg0KPiA+PiBObywgdGhpcyBvbmx5IGlzIGFi b3V0IHRoZSBHREIgcGFydCBvZiB0aGUgY29kZS4NCj4gPg0KPiA+R0NDIHN1 cHBvcnQgZm9yIElSSVggd2FzIGFscmVhZHkgcmVtb3ZlZCBhIGZldyB5ZWFy cyBhZ28uDQo+ID4NCj4gPlRoYW5rcywNCj4gPkFuZHJldw0KPiA+DQo+ID4+ DQo+ID4+PiArIGRvZXMgdGhpcyBoYXZlIHRoZSBzaWRlLWVmZmVjdCBvZiBp bXBhY3RpbmcgYW55IGVtYmVkZGVkIG1pcHMNCj4gPj4+IHRhcmdldHM/IEkg ZXhwZWN0IG5vdC4NCj4gPj4NCj4gPj4gTm8uIEZvciBNSVBTLCB0aGlzIHNo b3VsZCBvbmx5IGFmZmVjdCBuYXRpdmUgSVJJWCBzdXBwb3J0Lg0KPiA+Pg0K PiA+PiAtLQ0KPiA+PiBKb2VsDQoNCg== >From gdb-return-43708-listarch-gdb=sources.redhat.com@sourceware.org Fri Sep 12 12:22:48 2014 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 25972 invoked by alias); 12 Sep 2014 12:22:47 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 25959 invoked by uid 89); 12 Sep 2014 12:22:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Sep 2014 12:22:45 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1XSPs9-0001Gc-9r from Yao_Qi@mentor.com ; Fri, 12 Sep 2014 05:22:41 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.181.6; Fri, 12 Sep 2014 05:22:40 -0700 From: Yao Qi To: Joel Brobecker CC: Pedro Alves , Gareth McMullin , Subject: Re: question about ARM watchpoints References: <20140901085743.GG4981@adacore.com> <540903B0.3000009@redhat.com> <20140905035127.GA27655@adacore.com> Date: Fri, 12 Sep 2014 12:22:00 -0000 In-Reply-To: <20140905035127.GA27655@adacore.com> (Joel Brobecker's message of "Thu, 4 Sep 2014 20:51:27 -0700") Message-ID: <87ioktav6i.fsf@codesourcery.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: 2014-09/txt/msg00047.txt.bz2 Content-length: 2451 Joel Brobecker writes: Joel, I got the same result as yours on qemu. We have arm board, but the kernel is too old to support hardware watchpoint, so unable to see how it behaves on real hardware. > That's what I wanted to try too, and will do soon. As to why we never > heard of this before - the only affirmative answer would be from someone > better able to undertand the docs than me. But here's a wild guess: the > fact that GDB stopped one instruction too late is invisible to the user > 99% of the time. What triggered me seeing it was a change in code > generation which caused the update to be at the penultimate instruction > of a function. I wouldn't have seen it if the update was anywhere before > that. This (GDB stops 2 instructions after the variable update) causes fails in two fails for arm-none-eabi target on qemu, FAIL: gdb.base/recurse.exp: continue to first instance watchpoint, second= time FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, secon= d time GDB outputs: continue^M Continuing.^M Hardware watchpoint 3: b^M ^M Old value =3D 5^M New value =3D 120^M recurse (a=3D5) at ../../../../git/gdb/testsuite/gdb.base/recurse.c:21^M 21 }^M (gdb) FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, s= econd time while the test expects the program stops at the line "return": gdb_test "continue" \ "Continuing.*\[Ww\]atchpoint.*: b.*Old value =3D 5.*New value =3D 120.= *return.*" \ "continue to second instance watchpoint, second time" 19 b *=3D recurse (a - 1); 0x000001ca <+26>: ldr r3, [r7, #4] 0x000001cc <+28>: subs r3, #1 0x000001ce <+30>: adds r0, r3, #0 0x000001d0 <+32>: bl 0x1b0 0x000001d4 <+36>: adds r2, r0, #0 0x000001d6 <+38>: ldr r3, [r7, #12] 0x000001d8 <+40>: muls r3, r2 0x000001da <+42>: str r3, [r7, #12] <-- memory store 20 return b; 0x000001dc <+44>: ldr r3, [r7, #12] 21 } =3D> 0x000001de <+46>: adds r0, r3, #0 0x000001e0 <+48>: mov sp, r7 0x000001e2 <+50>: add sp, #16 As we can see, if GDB stops one instruction after the variable update (0x000001dc), the source line is correct, and fails will go away. These two fails were reported on 2012-09 in codesourcery, but we didn't analyze them until I start to fix these fails recently. --=20 Yao (=E9=BD=90=E5=B0=A7)