From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16891 invoked by alias); 17 Sep 2013 09:43:34 -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 16879 invoked by uid 89); 17 Sep 2013 09:43:33 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Sep 2013 09:43:33 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mga11.intel.com Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 17 Sep 2013 02:43:30 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 17 Sep 2013 02:43:29 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.69]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 10:43:28 +0100 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: RE: [patch v4 23/24] record-btrace: add (reverse-)stepping support Date: Tue, 17 Sep 2013 09:43:00 -0000 Message-ID: References: <1372842874-28951-1-git-send-email-markus.t.metzger@intel.com> <1372842874-28951-24-git-send-email-markus.t.metzger@intel.com> <20130818190935.GR24153@host2.jankratochvil.net> In-Reply-To: <20130818190935.GR24153@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00491.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Sunday, August 18, 2013 9:10 PM > To: Metzger, Markus T Thanks for your review. > > There's an open regarding frame unwinding. When I start stepping, the > > frame cache will still be based on normal unwinding as will the frame > > cached in the thread's stepping context. This will prevent me from > > detecting that i stepped into a subroutine. >=20 > Where do you detect you have stepped into a subroutine? That is up to GDB > after your to_wait returns, in handle_inferior_event. That's the place. I don't have any code that detects this. But this code compares a NORMAL_FRAME from before the step with a BTRACE_FRAME from after the wait. They will always be unequal hence we will never recognize that we just reverse-stepped into a function. When I reset the frame cache, GDB re-computes the stored frame and now compares two BTRACE_FRAMEs, which works OK. > > To overcome that, I'm resetting the frame cache and setting the > > thread's stepping cache based on the current frame - which is now > > computed using branch tracing unwind. I had to split > > get_current_frame to avoid checks that would prevent me from doing this. >=20 > This is not correct, till to_wait finishes the inferior is still executin= g and you > cannot query its current state (such as its frame/pc/register). >=20 > I probably still miss why you do so. See above. Alternatively, I might add a special case to frame comparison, but this would be quite ugly, as well. Do you have a better idea? > Proposing some hacked draft patch but for some testcases it FAILs for me; > but they FAIL even without this patch as I run it on Nehalem. I understa= nd I > may miss some problem there, though. >=20 >=20 > > It looks like I don't need any special support for breakpoints. Is > > there a scenario where normal breakpoints won't work? >=20 > You already handle it specially in BTHR_CONT and in BTHR_RCONT by > breakpoint_here_p. As btrace does not record any data changes that may > be enough. "record full" has different situation as it records data chan= ges. > I think it is fine as you wrote it. >=20 > You could handle BTHR_CONT and BTHR_RCONT equally to BTHR_STEP and > BTHR_RSTEP, just returning TARGET_WAITKIND_SPURIOUS instead of > TARGET_WAITKIND_STOPPED. > This way you would not need to handle specially breakpoint_here_p. > But it would be sure slower. I don't think performance is an issue, here. I tried that and it didn't se= em to stop correctly resulting in lots of test fails. I have not investigated= it. > > Non-stop mode is not working. Do not allow record-btrace in non-stop > mode. >=20 > While that seems OK for the initial check-in I do not think it is conveni= ent. > Some users use for example Eclipse in non-stop mode, they would not be > able to use btrace then as one cannot change non-stop state when the > inferior is running. You can just disable the ALL_THREADS cases in recor= d- > btrace.c, can't you? Record-full is not supporting non-stop, either. I'm wondering what other issues I might run into with non-stop mode that I am currently not aware of. > > + case BTHR_CONT: > > + /* We're done if we're not replaying. */ > > + if (replay =3D=3D NULL) > > + return btrace_step_no_history (); > > + > > + /* I'd much rather go from TP to its inferior, but how? */ >=20 > find_inferior_pid (ptid_get_pid (tp->ptid)) Although I do not see why you > prefer the inferior here. I need the address space which is stored in the inferior struct. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052