From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27406 invoked by alias); 2 Dec 2005 18:28:51 -0000 Received: (qmail 27398 invoked by uid 22791); 2 Dec 2005 18:28:50 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 18:28:49 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jB2ISCpm031799; Fri, 2 Dec 2005 19:28:12 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jB2ISBmH031205; Fri, 2 Dec 2005 19:28:11 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jB2IS9GO025281; Fri, 2 Dec 2005 19:28:09 +0100 (CET) Date: Fri, 02 Dec 2005 18:44:00 -0000 Message-Id: <200512021828.jB2IS9GO025281@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: jimb@red-bean.com CC: pgilliam@us.ibm.com, gdb-patches@sources.redhat.com In-reply-to: <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com> (message from Jim Blandy on Thu, 1 Dec 2005 17:07:24 -0800) Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()' References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00058.txt.bz2 > Date: Thu, 1 Dec 2005 17:07:24 -0800 > From: Jim Blandy > > Whatever we do immediately, the underlying cause here is that > unwinding isn't working at every instruction. If it were, then the > call to frame_find_by_id would find the frame containing the watched > variable, and watchpoint_check would correctly conclude that the > variable was still in scope. > > Paul, does your test program have Dwarf CFI for the functions in question? Unfortunately, GCC's CFI is not complete. At one point GCC did generate CFI for epilogues, but that really screwed up cases like: main: prologue jump to body epilogue: epilogue body: ... ... jump to epilogue whis GCC was generating quite a lot. So generating CFI for epilogues was disabled. I vaguely remember that Richard Henderson said that generating correct CFI for the above case would be possible with tree SSA. But I don't think this has ahppened yet. Actually I think the fact that CFI works at all is mostly because it is also used for exception handling. Obviously, generating correct CFI for the epilogue isn't terribly important for exception handling, since there is no code that can throw exceptions in the epilogue (although it becomes somewhat important if you allow for asynchronous exceptions). It'd be great if we could get some of the GCC hackers a bit more interested in gdb. Mark