From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15114 invoked by alias); 16 Dec 2011 15:17:20 -0000 Received: (qmail 15101 invoked by uid 22791); 16 Dec 2011 15:17:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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; Fri, 16 Dec 2011 15:17:06 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RbZWy-0001wd-Gz from pedro_alves@mentor.com ; Fri, 16 Dec 2011 07:17:04 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Dec 2011 15:17:02 +0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH] PR threads/10729: x86 hw watchpoints and non-stop mode Date: Fri, 16 Dec 2011 16:16:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.7.2; x86_64; ; ) Cc: Jan Kratochvil References: <201112051601.59664.pedro@codesourcery.com> <201112131801.20730.pedro@codesourcery.com> <20111213191858.GA30724@host2.jankratochvil.net> In-Reply-To: <20111213191858.GA30724@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112161516.56808.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00514.txt.bz2 Hi Jan, sorry for the delay. On Tuesday 13 December 2011 19:18:58, Jan Kratochvil wrote: > On Tue, 13 Dec 2011 19:01:20 +0100, Pedro Alves wrote: > > and get back to this once we have better support for > > testing everything in extended-remote mode. > > We will still need to test GDB in legacy mode for compatibility reasons with > non-FSF gdbservers and existing user setups of gdbserver. I do not see what > will change with adding the new extended-remote mode to the existing set of > modes required to be run. Currently, because there's no extended-remote board, the only way to be a bit certain that we aren't making extended-remote "attach"/"run" support in gdbserver a brick is the gdb.server/ tests. Let's take a look at what we're talking about: $ ls gdb.server/*.exp gdb.server/ext-attach.exp gdb.server/ext-run.exp gdb.server/file-transfer.exp gdb.server/server-mon.exp gdb.server/server-run.exp That's it. Once we have a board that tests the whole testsuite in extended-remote mote, the ext-*.exp tests become useless and redundant, and so all uses of gdbserver_start_extended can be eliminated -- we have plenty of regular tests that "run" and "attach". Meanwhile, we don't such a board, so we live with the exception that the tests force gdbserver, and extended-remote. This is what I mean by revisiting later. (I don't see a point in adding a board variable for "supports extended-remote" at this point.) The other tests don't directly relate to the gdbserver_start_extended discussion, but let's have a look for completeness. The file-transfer.exp test could be adjusted to not require gdbserver, but instead detect the remote or extended-remote target is being used, and skipped if not. E.g., "remote put" fails with "command can only be used with remote target" if used on any other target. With that adjustment, the test could be moved elsewhere. The gdb.server/server-mon.exp test exercise gdbserver (vs any other 3rd-party server) specific bits. We could perhaps adjust it to try "monitor help" or "monitor version" (the latter doesn't work today, but it'd be reasonable to add), and skipping the test if something not gdbserver comes out. Such a change assumes PASS->UNSUPPORTED or PASSes simply disappearing kind of regressions are detected, but they should anyway. The server-run.exp test is practically useless everywhere. It's a tiny bit useful on [istarget *-*-linux*], and the bit it tests can only work as expected on use_gdb_stub boards. So we could move it to say, gdb.base/, and adjust it to not require gdbserver, and skip it if !use_gdb_stub. > > > As a less ambitious change if you do not like gdbserver_start_extended in this > > > testcase we can change it. > > > > That'd be my preference. > > AFAIK there currently does not exist any extended-mode board file so there > does not make sense to check in a testcase requiring it. The test works with the native target. It would be skipped for use_gdb_stub boards, like many tests are. It looks worth it to check in to me. What I disagree is spreading gdbserver_start_extended uses outside of gdb.server/. Jan, largely, we agree. Really. > > > But gdb.server/ext-*.exp do exactly the same so they have to be > > > changed all together. > > > > I disagree, they don't have to. > > With http://sourceware.org/gdb/wiki/TestingGDB#Native_Board_File they both run > the server in extended mode. > > There is a difference in default mode gdb.server/ext-*.exp also run it in > extended mode while this testcases runs in linux-nat mode in such case. I was disagreeing in your claim that they have to be changed all together... We can just simply put your test case in, without the gdbserver_start_extended bit, skipped on use_gdb_stub, and leave the gdb.server/ tests alone for a separate patch/change/discussion/whatever. They _don't_ have to be changed all together, is what I'm saying. Maybe I misunderstood you. > Our opinion probably differs in that I find running GDB testing only in the > default mode as insufficient. Of course we agree here. You were the one complaining that the tests run in all modes... -- Pedro Alves