From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15211 invoked by alias); 15 Sep 2015 02:25:28 -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 15190 invoked by uid 89); 15 Sep 2015 02:25:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham 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; Tue, 15 Sep 2015 02:25:24 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1Zbfvp-00003L-0t from Sandra_Loosemore@mentor.com ; Mon, 14 Sep 2015 19:25:19 -0700 Received: from [IPv6:::1] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Mon, 14 Sep 2015 19:25:16 -0700 Message-ID: <55F7815F.1010602@codesourcery.com> Date: Tue, 15 Sep 2015 02:25:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches , Yao Qi Subject: Re: [RFC] fix gdb.threads/non-stop-fair-events.exp timeouts References: <55E9CCCD.7060604@codesourcery.com> <55EF0D11.2020200@redhat.com> <55F05975.4030207@codesourcery.com> <55F07D12.7090607@redhat.com> In-Reply-To: <55F07D12.7090607@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00303.txt.bz2 On 09/09/2015 12:40 PM, Pedro Alves wrote: > On 09/09/2015 05:08 PM, Sandra Loosemore wrote: >> On 09/08/2015 10:30 AM, Pedro Alves wrote: >>> >>> Yeah, I've seen this before with a local series I use for debugging >>> software single-step things that implements software single-stepping >>> on x86. I just re-tried it now after rebasing that series to >>> current mainline, and I still see the time outs against gdbserver. >>> >>> AFAICS, nios2 is a software single-step target that does not implement >>> displaced stepping either. I had a patch for this that I had >>> never posted. See attached. >>> >> >> Hmmm, these two patches are not working for me. The trouble is that >> this part: >> >>> +gdb_test_multiple "si" $msg { >>> + -re "displaced pc to.*$gdb_prompt $" { >>> + set displaced_stepping_enabled 1 >>> + } >>> + -re ".*$gdb_prompt $" { >>> + } >>> +} >> >> is causing the target to step from main to pthread_self, which is in a >> different file. This causes the subsequent breakpoint commands to fail, >> and things go south from there: > > OK, I got "lucky" on x86 and a stepi runs some instruction before the call. > Could you try simply replacing the "si" with "next" ? It doesn't matter > whether that issues several single-steps or not. What matters is that gdb > tries to step past the breakpoint that is set at the current PC (from the > earlier runto_main). We're trying to figure out if gdb uses displaced > stepping for that. Yes, that fixes the trouble, and the tests run OK now. I did find that it still timed out 1 of the 5 times I ran it, though, so maybe the timeout factor really does need to match NUM_THREADS to be safe? -Sandra