From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11678 invoked by alias); 8 Dec 2011 18:40:00 -0000 Received: (qmail 11669 invoked by uid 22791); 8 Dec 2011 18:39:58 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Dec 2011 18:39:44 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1RYisg-0001KF-RP from Maciej_Rozycki@mentor.com ; Thu, 08 Dec 2011 10:39:42 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 10:39:12 -0800 Received: from [172.30.5.182] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 8 Dec 2011 18:39:40 +0000 Date: Thu, 08 Dec 2011 18:56:00 -0000 From: "Maciej W. Rozycki" To: Tom Tromey CC: Joel Brobecker , Subject: Re: one-too-many location in breakpoint In-Reply-To: Message-ID: References: <20111123163917.GA13809@adacore.com> <20111123232406.GQ13809@adacore.com> <20111124105603.GA91879@adacore.com> <20111124163304.GR13809@adacore.com> <20111129033329.GS24943@adacore.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2011-12/txt/msg00272.txt.bz2 On Tue, 29 Nov 2011, Tom Tromey wrote: > Tom> I fixed all the other problems. I'm running a regression test to make > Tom> sure I didn't make something else break while doing this. If all goes > Tom> well I will send out refreshed patches. > > I needed a couple of test suite changes to account for the different > output. Otherwise all is well. > > This includes a test addition for the iterate_over_symbols change. > > I didn't write a new test for the "normal_menu" problem. Just as a heads-up, this has regressed on the mips-sde-elf target (both MIPS32 and MIPS16 multilibs) as follows: break A::outer::foo (char*) const if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break A::outer::foo (char*) const if (a == 3) break 'A::outer::foo (char*) const' if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break 'A::outer::foo (char*) const' if (a == 3) [...] break A::outer::foo (int) const if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break A::outer::foo (int) const if (a == 3) break 'A::outer::foo (int) const' if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break 'A::outer::foo (int) const' if (a == 3) [...] break A::B::inner::foo (char*) const if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break A::B::inner::foo (char*) const if (a == 3) break 'A::B::inner::foo (char*) const' if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break 'A::B::inner::foo (char*) const' if (a == 3) [...] break A::B::inner::foo (int) const if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break A::B::inner::foo (int) const if (a == 3) break 'A::B::inner::foo (int) const' if (a == 3) No symbol "a" in current context. (gdb) FAIL: gdb.cp/ovsrch.exp: break 'A::B::inner::foo (int) const' if (a == 3) No regressions on mips-linux-gnu though. This is SDE code: 800011e8 : 800011e8: 27bdfff8 addiu sp,sp,-8 800011ec: afbe0004 sw s8,4(sp) 800011f0: 03a0f021 move s8,sp 800011f4: 03c0e821 move sp,s8 800011f8: 8fbe0004 lw s8,4(sp) 800011fc: 27bd0008 addiu sp,sp,8 80001200: 03e00008 jr ra 80001204: 00000000 nop (breakpoint at 800011f4), and this is Linux code: 00400790 : 400790: 27bdfff8 addiu sp,sp,-8 400794: afbe0004 sw s8,4(sp) 400798: 03a0f021 move s8,sp 40079c: 03c0e821 move sp,s8 4007a0: 8fbe0004 lw s8,4(sp) 4007a4: 27bd0008 addiu sp,sp,8 4007a8: 03e00008 jr ra 4007ac: 00000000 nop (breakpoint at 40079c). And I fail to see "a" being defined anywhere throughout gdb.cp/ovsrch*, so I am curious as to why it succeeds for any target (including mips-linux-gnu) in the first place. I can see you made this adjustment: - gdb_test "break ${class}::foo if (a == 3)" "Breakpoint (\[0-9\]).*" + gdb_test "break ${class}::hibob if (a_param == 3)" "Breakpoint but there's this definition elsewhere in this test case: set conditional1 "if (a == 3)" as well, that you have left intact. Should it be adjusted accordingly? Why is this condition accepted for some targets and not for some others anyway? Thoughts? Maciej