From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25618 invoked by alias); 20 Oct 2005 00:18:13 -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 25020 invoked by uid 22791); 20 Oct 2005 00:16:52 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 20 Oct 2005 00:16:51 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j9K0GoRM023105 for ; Wed, 19 Oct 2005 20:16:50 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j9K0GnV05471; Wed, 19 Oct 2005 20:16:49 -0400 Received: from theseus.home..redhat.com (vpn26-16.sfbay.redhat.com [172.16.26.16]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j9K0GlGG003654; Wed, 19 Oct 2005 20:16:48 -0400 To: gdb@sourceware.org Subject: Why do we have two ways of finding sniffers? From: Jim Blandy Date: Thu, 20 Oct 2005 00:18:00 -0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-10/txt/msg00105.txt.bz2 Looking at frame-unwind.c and frame-unwind.h, it seems like there are two mostly equivalent ways to register frame unwinding methods. Why do we have two ways, instead of just one? The comments in frame-unwind.h don't really explain why it's helpful. The only function that scans the list of unwinders is frame_unwind_by_frame: it takes a NEXT frame, and returns a 'struct frame_unwind *' if it can find one. It works by walking the NEXT frame's gdbarch's list of frame unwinders. Each entry in the list is one of two possible kinds: - If the entry points to a frame_unwind_sniffer_ftype function, that takes the next frame's frame_info; if it likes it, then it returns a 'struct frame_unwind *' to use for this frame. - If the entry points to a 'struct frame_unwind' object, that contains its own sniffer, which takes a pointer to the 'struct frame_unwind', the next frame's frame_info, and a prologue cache, and just returns a boolean indicating whether this is an appropriate frame_unwind for it. I don't understand why we need both alternatives. Shouldn't it be sufficient to simply have each entry in the list point to a function that expects the next frame's frame_info and a prologue cache, and returns a 'struct frame_unwind *' or zero?