From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20235 invoked by alias); 20 May 2013 18:29:06 -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 20204 invoked by uid 89); 20 May 2013 18:29:03 -0000 X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 20 May 2013 18:29:02 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4KIT0u5005139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 May 2013 14:29:00 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4KISwtw018718; Mon, 20 May 2013 14:28:59 -0400 Message-ID: <519A6B6A.1030107@redhat.com> Date: Mon, 20 May 2013 18:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 6/7] range stepping: test case References: <1363006291-13334-1-git-send-email-yao@codesourcery.com> <1363006291-13334-7-git-send-email-yao@codesourcery.com> <51928327.5080803@redhat.com> <519346F0.1030507@codesourcery.com> In-Reply-To: <519346F0.1030507@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00739.txt.bz2 On 05/15/2013 09:27 AM, Yao Qi wrote: > On 05/15/2013 02:32 AM, Pedro Alves wrote: >> I prefer this over the convenience variable hack. If we ever >> make range stepping work on a target !remote, we can switch to >> look at "set debug infrun 1" output or some new "set debug range-step" >> output. I didn't understand your stated reason in v2 for >> switching away from this. If it was that expect buffer >> overflows, v3 has a tweak that likely fixes it. > > In our tests, when running tests with a problematic stub supporting range > stepping, the range stepping of the stub falls back to the single stepping. > This will generate a huge number of rsp packets, and the gdb.log will blow up > to several giga-byte. I see. Thanks, that's much more detailed info than just saying "it's unsafe". I'm guessing the huge number of RSP packets comes from that big loop in the test: /* Generate a range that includes a loop, which is time consuming. Variable C is used to terminate the loop earlier when GDB wants. */ for (c = 1, a = 0; a < 65535 && c; a++) {for (b = 0; b < 65535 && c; b++) { d1 = d2 * a / b; d2 = d1 * We could skip most of the range stepping tests if e.g., the test that steps the short line FAILs: /* A line of source will be generated to a number of instructions by compiler. */ a = b + c + d * e - a; /* location 1 */ WDYT? > We use convince variable to avoid this problem. On the other > hand, I don't think it is a good idea to peek the GDB internal states by > checking some rsp packets and personally I prefer the way that GDB is able to expose > some internal states by some means (command "maint" and convince variables, for example). I don't like using a convenience variable for this, as those are visible to the user (show convenience). "maint" seems better. But I'm not certain of it. An issue I have with it is that from the log you just see the condensed report of what happened (sent 4 vCont;r, should have been 3), while to diagnose the issue you'll most likely need to get more info than that ("Okay, what was really sent? What were the ranges? Were there signals interrupting the range? Etc."). I have a suspicion we'll end up needing to end up with "set debug infrun 1" on, and look at that too for some of the trickier cases, and end up with different number of expected ranges depending on target on some cases. The actual difference between v1 -> v2 wrt to the RSP packets vs convenience var was surprisingly smaller than I anticipated. So how about we go with RSP first, and see how things go from there? -- Pedro Alves