From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20274 invoked by alias); 10 May 2003 10:47:37 -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 19952 invoked from network); 10 May 2003 10:47:31 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 10 May 2003 10:47:31 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h4AAlUXX004288 for ; Sat, 10 May 2003 12:47:30 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h4AAlUXI037803 for ; Sat, 10 May 2003 12:47:30 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h4AAlUuM037800; Sat, 10 May 2003 12:47:30 +0200 (CEST) Date: Sat, 10 May 2003 10:47:00 -0000 Message-Id: <200305101047.h4AAlUuM037800@elgar.kettenis.dyndns.org> From: Mark Kettenis To: gdb@sources.redhat.com Subject: [RFC] Special type for the sentinel frame? X-SW-Source: 2003-05/txt/msg00181.txt.bz2 Note the comment in the following fragment from sentinel-frame.c: const struct frame_unwind sentinel_frame_unwinder = { /* Should the sentinel frame be given a special type? */ NORMAL_FRAME, sentinel_frame_this_id, sentinel_frame_prev_register }; I think the answer to this question is yes. The following code in blockframe.c would certainly benefit from it: /* return the address of the PC for the given FRAME, ie the current PC value if FRAME is the innermost frame, or the address adjusted to point to the call instruction if not. */ CORE_ADDR frame_address_in_block (struct frame_info *frame) { CORE_ADDR pc = get_frame_pc (frame); /* 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; } Since the answer to the question in the FIXME would again be yes. 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. Thoughts? Andrew? Mark