From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6868 invoked by alias); 13 Jun 2011 16:11:44 -0000 Received: (qmail 6859 invoked by uid 22791); 13 Jun 2011 16:11:43 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 16:11:18 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5DGBIID025084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Jun 2011 12:11:18 -0400 Received: from host1.jankratochvil.net (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5DGBGab021974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Jun 2011 12:11:17 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p5DGBFHf029897; Mon, 13 Jun 2011 18:11:15 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p5DGBEpm029891; Mon, 13 Jun 2011 18:11:14 +0200 Date: Mon, 13 Jun 2011 16:11:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: Regression: Re: [PATCH] Fix some i386 unwinder inconcistencies Message-ID: <20110613161114.GA18588@host1.jankratochvil.net> References: <201106122057.p5CKvUEa030437@glazunov.sibelius.xs4all.nl> <20110613104911.GA1965@host1.jankratochvil.net> <201106131537.p5DFb1cn023164@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106131537.p5DFb1cn023164@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) 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-06/txt/msg00165.txt.bz2 On Mon, 13 Jun 2011 17:37:01 +0200, Mark Kettenis wrote: > > -PASS: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint > > +FAIL: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint > > Odd, that tests still passes for me on i386-unknown-openbsd4.9. >From the error message > > +can't compute CFA for this frame on Fedora I guess it may be because the compiler there does not produce the optimized DWARF form: <35> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) > PASS: gdb.base/watchpoint-cond-gone.exp: Catch the no longer valid watchpoint > > Something did change though. Before my change: In both cases on Fedora it stops at the same place: 0x080483e0 in func () at ./gdb.base/watchpoint-cond-gone.c:28^M Which seems correct to me as it is -O0 -g code, therefore without variable tracking for instruction-precise DW_AT_location, therefore variables become invalid by the `leave' instruction: 80483df: c9 leave 80483e0: c3 ret > Something did change though. Before my change: > So the watchpoint went out of scope before the function returned. Yes, because the frame got destroyed, the variable is no longer valid. > Whereas after my change: > the watchpoint went out of scope when the function returned, as I believe it should. I do not agree, when you stop at the `ret' instruction above the watchpoint should be already deleted there because its watched variable is no longer valid. > > -XFAIL: gdb.mi/mi-watch.exp: sw: watchpoint trigger (stopped at wrong place) > > +XFAIL: gdb.mi/mi-watch.exp: sw: watchpoint trigger (unknown output after running) > > -XFAIL: gdb.mi/mi2-watch.exp: sw: watchpoint trigger (stopped at wrong place) > > +XFAIL: gdb.mi/mi2-watch.exp: sw: watchpoint trigger (unknown output after running) > > Ok, I'm seeing these as well. Didn't classify these as a regression > since they went from XFAIL to XFAIL. They seem to be related to the > fact that I changed get_frame_pc into get_frame_func. That change is > correct though. If you believe it is correct then you should fix the testcase. I find "(stopped at wrong place)"->"(unknown output after running)" to be a regression. But as there is printed: +&"can't compute CFA for this frame\n"^M I find the message as a regression on its own. > I think this can be avoided by implementing the > in_function_epilogue_p() gdbarch method for i386/amd64. In fact, that > method already seems to be implemented. It just isn't registered. After `leave' the local variables are no longer valid, they are already located under $sp and can be overwritten by any interrupt that time, no GDB unwinder can fix it. Also for the epilogue unwinder you would need to somehow fix: 1441 /* This restriction could be lifted if other unwinders are known to 1442 compute the frame base in a way compatible with the DWARF 1443 unwinder. */ 1444 if (! frame_unwinder_is (this_frame, &dwarf2_frame_unwind)) 1445 error (_("can't compute CFA for this frame")); Thanks, Jan