From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-22801-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 31732 invoked by alias); 20 Oct 2005 00:25:49 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 31715 invoked by uid 22791); 20 Oct 2005 00:25:47 -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:25:47 +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 j9K0PjC1025907
	for <gdb@sourceware.org>; Wed, 19 Oct 2005 20:25:45 -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 j9K0PeV07202;
	Wed, 19 Oct 2005 20:25:40 -0400
Received: from theseus.home..redhat.com (vpn26-8.sfbay.redhat.com [172.16.26.8])
	by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j9K0PcT3005201;
	Wed, 19 Oct 2005 20:25:39 -0400
To: gdb@sourceware.org
Subject: Re: Why do we have two ways of finding sniffers?
References: <vt2slux2gb5.fsf@theseus.home.>
From: Jim Blandy <jimb@redhat.com>
Date: Thu, 20 Oct 2005 00:25:00 -0000
In-Reply-To: <vt2slux2gb5.fsf@theseus.home.> (Jim Blandy's message of "Wed, 19 Oct 2005 17:16:46 -0700")
Message-ID: <vt2oe5l2fwd.fsf@theseus.home.>
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/msg00106.txt.bz2


Jim Blandy <jimb@redhat.com> writes:
> 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?

I guess we'd also need a void * passed through to the function, to
support things like tramp_frame_prepend_unwinder.