From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14992 invoked by alias); 10 May 2003 14:08:52 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14736 invoked from network); 10 May 2003 14:08:48 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 10 May 2003 14:08:48 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0C4DE2B4E; Sat, 10 May 2003 10:08:48 -0400 (EDT) Message-ID: <3EBD07EF.6010805@redhat.com> Date: Sat, 10 May 2003 14:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: [RFC] Special type for the sentinel frame? References: <200305101047.h4AAlUuM037800@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00182.txt.bz2 > /* If we are not in the innermost frame, and we are not interrupted > by a signal, frame->pc points to the instruction following the > call. As a consequence, we need to get the address of the previous > instruction. Unfortunately, this is not straightforward to do, so > we just use the address minus one, which is a good enough > approximation. */ > /* FIXME: cagney/2002-11-10: Should this instead test for > NORMAL_FRAME? A dummy frame (in fact all the abnormal frames) > save the PC value in the block. */ > if (get_next_frame (frame) != 0 > && get_frame_type (get_next_frame (frame)) != SIGTRAMP_FRAME) > --pc; > > return pc; > } Here's a better set of comments: struct frame_unwind { /* The frame's type. Should this instead be a collection of predicates that test the frame for various attributes? */ enum frame_type type; /* Should an attribute indicating the frame's address-in-block go here? */ frame_this_id_ftype *this_id; frame_prev_register_ftype *prev_register; }; > Decreasing PC here would be wrong for sentinel frames in the same way > as it is wrong for dummy frames and signal trampolines. > > The reason I bring this to your attention, is that I'm facing a > similar situation in the DWARF CFI frame unwinder. Of course I can > detect the sentinel frame by looking at the relative frame level. > However, having a seperate frame type for the sentinel frame makes > things cleaner IMHO. I think it should be an attribute, or at least a function that localises the logic for determining if/when things should be decremented. Otherwize, everytime someone adds a new frame type, they have to audit all the calls to determine if additioinal changes are needed. I suspect that get_frame_type() and this ever increasing list of frame types should be eliminated. Andrew