From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32751 invoked by alias); 28 Jul 2012 00:10:59 -0000 Received: (qmail 32728 invoked by uid 22791); 28 Jul 2012 00:10:53 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL 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; Sat, 28 Jul 2012 00:10:39 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Suuc8-0002zh-Kl from Maciej_Rozycki@mentor.com ; Fri, 27 Jul 2012 17:10:36 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jul 2012 17:10:36 -0700 Received: from [172.30.4.73] (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; Sat, 28 Jul 2012 01:10:33 +0100 Date: Sat, 28 Jul 2012 00:10:00 -0000 From: "Maciej W. Rozycki" To: Jan Kratochvil CC: Joel Brobecker , Philippe Waroquiers , Pedro Alves , Subject: Re: [patchv2] Write bpt at the ON_STACK bpt address In-Reply-To: <20120727160200.GA6628@host2.jankratochvil.net> Message-ID: References: <1343074047.2209.23.camel@soleil> <20120723201611.GA19567@host2.jankratochvil.net> <1343075809.2209.53.camel@soleil> <501009AE.40901@redhat.com> <1343247870.2240.29.camel@soleil> <20120725212653.GC2767@adacore.com> <1343252775.2240.51.camel@soleil> <20120725223933.GD2767@adacore.com> <20120726212339.GA1710@host2.jankratochvil.net> <20120727160200.GA6628@host2.jankratochvil.net> 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: 2012-07/txt/msg00712.txt.bz2 On Fri, 27 Jul 2012, Jan Kratochvil wrote: > > Does it need native testing or is remote testing enough to cover it? > > I do not think it matters, infcalls work the same for both. Breakpoints may be inserted differently on some remote targets, but that's more a matter of Linux vs bare-iron targets. Anyway, thanks for confirming that no native testing is required, this is always problematic. > As Philippe has already tested mips compatibility with valgrind only GDB > testsuite in some of the appropriate MIPS ISAs would be nice before I check it > in also for 7.5. I have tested your change now, applied on top of current trunk and that caused no regressions throughout all the configurations involved, so it looks good to go in as far as I'm concerned. Sadly there are some regressions in the baseline I used, compared to the last previous test results I obtained a couple weeks ago. Specifically these: FAIL: gdb.base/dprintf.exp: 1st dprintf, gdb FAIL: gdb.base/dprintf.exp: 2nd dprintf, gdb FAIL: gdb.base/list.exp: list range; filename:line1,filename:line2 FAIL: gdb.base/list.exp: list range; line1,line2 FAIL: gdb.base/list.exp: list range; upper bound past EOF FAIL: gdb.base/list.exp: list range; both bounds past EOF FAIL: gdb.base/list.exp: list range, must be same files FAIL: gdb.linespec/ls-errs.exp: break 3: FAIL: gdb.linespec/ls-errs.exp: break +10: FAIL: gdb.linespec/ls-errs.exp: break -10: FAIL: gdb.linespec/ls-errs.exp: break 3: FAIL: gdb.linespec/ls-errs.exp: break +10: FAIL: gdb.linespec/ls-errs.exp: break -10: FAIL: gdb.linespec/ls-errs.exp: break 3 : FAIL: gdb.linespec/ls-errs.exp: break +10 : FAIL: gdb.linespec/ls-errs.exp: break -10 : FAIL: gdb.linespec/ls-errs.exp: break 3 : FAIL: gdb.linespec/ls-errs.exp: break +10 : FAIL: gdb.linespec/ls-errs.exp: break -10 : (notice the test message duplication in the last series -- that's a bug by itself). Do any of these ring anyone's bell? They appear across both Linux and bare-iron configurations and all multilibs so must be pretty generic and from the log files they look genuine. Regrettably I haven't yet grown myself a regular overnight testing facility so that I could catch such issues early. Maciej